GuidesOnly show guides for your app
GuidesGuidesStop debugging in production. Set up a second bot application, a private test server, and the guild-scoped registration trick that makes command changes appear instantly — then run it on Falix as a second instance or a second server.
The fastest way to embarrass your bot is to test a half-finished command in the server people actually use. A proper test setup fixes that: a throwaway test bot, a private test server to break things in, and a registration trick that makes your changes show up instantly instead of minutes later. None of it costs anything.
| At a glance | |
|---|---|
| You need | a working bot and a Discord account |
| Plan | free or premium |
| Time | about twenty minutes |
In Discord, create a new server (the + button → Create My Own). It's yours; invite no one. This is where you'll run every experiment — spam commands, trigger errors, wipe test data — with zero audience.
Make a separate application in the Developer Portal, exactly like your first one, and get its own token from Bot → Reset Token. Invite this test bot to your private server only.
Why a second app instead of reusing your real one? Isolation. The test bot can go offline, throw errors, or run broken code all day and your real bot — a different application, a different token — never notices. Keep the two tokens straight in .env:
DISCORD_TOKEN=your_test_bot_token
TEST_GUILD_ID=your_private_server_id
⚠️ Heads up: The test bot needs the same intents toggled in its Developer Portal page. Each application has its own intent switches — enabling them on your real bot does nothing for the test one.
By default you register commands globally, and global commands can take several minutes to appear the first time and to update — painful when you're iterating. The fix: while developing, register commands to your test guild instead. Guild-scoped commands update instantly.
application.commands.set() takes an optional guild ID as its second argument:
client.once('ready', async (c) => {
const commands = [ /* your SlashCommandBuilders */ ];
if (process.env.TEST_GUILD_ID) {
// Development: instant updates in your test server.
await c.guilds.cache.get(process.env.TEST_GUILD_ID)?.commands.set(commands);
} else {
// Production: global, available everywhere (with the first-time delay).
await c.application.commands.set(commands);
}
console.log(`Listening as ${c.user.tag}`);
});
Now editing a command and restarting shows the change in seconds. When you ship to the real bot, leave TEST_GUILD_ID unset and it registers globally. This single change is the biggest quality-of-life win in bot development.
You've got the test bot's code — now it needs somewhere to run. Two honest options:
An instance is an isolated profile on one server: its own files, startup, and variables, up to 10 per server. Put your test bot in a second instance and switch between "production" and "test" like save slots.
Create a separate Falix server for the test bot.
| Second instance | Second server | |
|---|---|---|
| Both run at once | no | yes |
| Extra free-plan timer | no | yes |
| Isolation | full (own files/startup) | full |
| Best when | you test in bursts | you need both live together |
dev branch).That loop keeps every mistake where nobody can see it.
TokenInvalid) — you used the real bot's token, or didn't reset/copy the test app's own token. Each application has its own.