Build a safe place to test your bot

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.

The three pieces

1. A private Discord server — your sandbox.
2. A second bot application — a separate token, so a crash or bad deploy never touches your real bot.
3. Guild-scoped commands — the trick that makes edits appear instantly.

1. A private test server

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.

2. A second bot application

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.

3. The instant-feedback trick

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.

Where to run it on Falix

You've got the test bot's code — now it needs somewhere to run. Two honest options:

Option A — a second instance on the same server

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.

• Good: no second server, no second timer to feed.
• Trade-off: only one instance runs at a time — activating the test instance means stopping the production one (the panel does it for you when you switch). Fine when you test in bursts.

Option B — a second server

Create a separate Falix server for the test bot.

• Good: production and test run at the same time — you can compare them live.
• Trade-off: on the free plan that's a second session timer to keep extended. See Keep your bot online.

A clean workflow

1. Edit code.
2. Deploy it to the test bot in your private server (upload, or Git deploy a dev branch).
3. Run the command; watch the console; break it on purpose.
4. Only when it's solid, ship the same code to your real bot.

That loop keeps every mistake where nobody can see it.

Troubleshooting

• Test commands still take minutes to update — you registered globally. Pass the test guild ID as shown above.
• Test bot won't log in (TokenInvalid) — you used the real bot's token, or didn't reset/copy the test app's own token. Each application has its own.
• Both bots reply to the same command — the test bot is in a real server it shouldn't be. Keep it in the private server only.
• "Server must be stopped" when switching instances — expected; an instance switch stops the current one first. See Instances.

Next steps

• Run separate apps with instances
• Keep your bot online
• Deploy your code with Git