Yours to run.
Forever.

What you need

• Docker and Docker Compose. The compose file runs the bot and Postgres together, so there is nothing else to install.
• A Discord application and bot token. Free, and it takes a couple of minutes to set up in the next section.

Create your Discord app

Head to the Discord Developer Portal and create a new application. Under Bot, grab the token. That becomes your DISCORD_TOKEN. The application id on the General Information page is your CLIENT_ID.

While you are there, turn on the two privileged intents: Server Members and Presence. It is a one-time toggle. The Presence intent is what lets game-aware templates (like @@game_name@@) see what your members are playing. Without it, those templates cannot do their thing.

Configure and launch

git clone https://github.com/GregZaal/Auto-Voice-Channels
cd Auto-Voice-Channels
cp .env.example .env
# edit .env: set DISCORD_TOKEN and CLIENT_ID
docker compose up -d

That is the whole setup. The default DATABASE_URL in .env.example already matches the Postgres that compose starts, so the only two values you fill in are your token and client id. On boot, database migrations run automatically and slash commands register themselves. No manual steps, no registration scripts.

Config is checked at startup, so if something is missing or malformed the process stops right away with a clear message instead of limping along.

Day two

• Updates. Run git pull, then docker compose up -d --build. Migrations only ever add before they remove, so upgrading is safe.
• Health. The bot serves GET /health on port 8080 (per subsystem: database, shard leases, gateway), plus GET /diagnostics for live state.
• Alerts. Set ADMIN_CHANNEL_ID to a text channel id and the bot posts significant errors there, such as a gateway failure or a command that could not finish. It is off by default, and without it those problems only ever show up in the container logs.
• Backups. Everything lives in Postgres, so back up that volume and you have backed up the whole bot.
• Bringing your config across. Worth doing before you start from scratch. /export downloads a server's whole AVC configuration as a file, and /import reads it back on your own instance. It also reads a config file from the old Python bot, so you do not have to retype years of setup. Both need Manage Server, and /import previews every change and attaches your previous configuration to the result, so you can put it back.
  Remove the other bot first. The channel ids are the same in both, so if the hosted bot is still in the server after you import, both bots will create a room every time somebody joins a creator channel. That is the one thing that goes wrong every time, and it looks like the import broke something.
• Coming from the old Python bot with a lot of servers? /import reads one of its config files per server, which is the right tool for a handful. If you have a whole guilds/ directory of them, the bulk importer that moved 5,556 servers onto this codebase is in your container too, and it is dry-run by default:
  node core/dist/migrate/import-cli.js ./guilds --live-guilds ids.txt
  It prints what it would do and changes nothing until you add --apply. It needs the bot stopped, and it reads snowflakes correctly, which matters: the old bot wrote them as JSON numbers and a plain parse silently corrupts every id above 2⁵³.

What hardware do I need

It depends on how many total members you have, and how active they are. The calculator above shows the recommended minimums, but in a nutshell:

• RAM. 300MB base (bot, Postgres, container) plus 1.28KB per member, times 1.5 for spike headroom.
• CPU. Shared vCPU under 10,000 members. 1 dedicated vCPU from 10,000. 2 dedicated vCPUs from 1,000,000.
• Database. Bundled with the bot under 100,000 members. Its own managed instance from 100,000. A bigger one from 1,000,000.

Treat every figure as a starting point, not a guarantee. It's easy enough to scale up if you need more.

The AVC logo

The AVC logo is not covered by the open source license, it's our intellectual property.

If you're self-hosting the bot for your own private server, you're welcome to use it.

But if you're hosting a bot for anyone else, we don't want anyone to be confused about which is the "official" AVC, so you can't use our logo there.

AGPL-3.0, in plain terms

Open source goes both ways.

You can read, run, change, and fork the exact code we host, not a stripped-down community edition. If you distribute it, including running a modified version as a service for others, you share your changes under the same license. That is the deal that keeps the project open, and the guarantee that we can never quietly turn closed or paywalled: you already have the code, and you can take it and go.

The hosted service is the same code with zero ops, and paying for it is what funds development. If running it yourself is not your idea of a good time, take a look at pricing. Every feature is free on every tier either way.