Discord bot + game server on the same VPS: when it works, when the bot kills the wipe

Quick reality check: A ticket bot and a Paper server with twelve friends on the same VPS is often fine. That same bot plus Lavalink plus Rust on a force wipe is not. Linux will not kill the bot first. Linux kills the process that wants the most RAM in that minute — and during wipe that is the game server. Map gen dies, Oxide hangs, the clan loads an empty world. That is the pattern in our out-of-memory guide.

The bot is not “attacking”. It is in the way when CPU and RAM have no headroom. You do not see that on a Tuesday night. You see it when everyone joins at once.

When it works

• Small bot: tickets, roles, a status embed, a few slash commands. Idle often 150–400 MB. No Lavalink, no Puppeteer, no local LLM.
• Light game: Paper/Purpur with few plugins — RAM is in the Minecraft hardware numbers. A small FiveM test box from the FiveM hardware guide, plus TeamSpeak. Not Rust on a procedural map, not 64-slot ESX with 200 resources.
• Real reserve: not “8 GB, it will be fine”. Rust idle plus wipe peak plus bot plus OS. If the peak fills RAM, the plan is wrong — panel or not.
• Put the bot in a corner: its own systemd unit with MemoryMax. The bot may swap or die. The game server may not.

Rule of thumb: if you can stop the bot for a week and nobody notices except the Discord channel, it does not belong on the wipe box.

When the bot kills the wipe

• Music / Lavalink: one Node plus decoders easily adds 0.5–2 GB and GC pauses. Right when Rust is writing the map.
• Rust force wipe: 3 September, 19:00 UK, the dedicated rebuilds the world. One-core CPU spike, RAM spike, disk burst. A neighbour with its own GC or an npm start after reboot is enough. Walkthrough: Rust docs.
• Everything starts together: VPS reboot, Pterodactyl, Rust, MariaDB, bot, Lavalink. The OOM killer picks the biggest victim. Spoiler: not the 200 MB bot.
• Backup cron in the same minute: snapshot or tar on the world while the map is coming up. I/O wait, then timeout, then “server not responding”. Backup and restore belong next to the wipe, not on top of it.
• Windows VPS: higher baseline. The same load that still fits on Linux tips over earlier.

FiveM after an artifact bump and Minecraft with heavy plugins are the same pattern: a start spike, not idle. If you only check htop at 03:00, you are planning from the wrong number — measure the peak like in the monitoring guide.

Checklist before you put both on one box

1. Measure the peak, not idle. Wipe, map load, first join, backup. free -h and the CPU steal line. Steal > 0 on the vCore the game needs alone: wrong plan, not “bot too fat”.
2. Cap the bot. systemd: MemoryMax=512M (or what it actually needs). Without a cap it shares the OOM with Rust.
3. Not the same minute. Stagger wipe, restart, backup, apt upgrade and bot deploys. One timer, not five.
4. Music and AI elsewhere. Lavalink, Whisper, Ollama — a small extra VPS. Port 11434 open to the net is its own problem anyway.
5. Game on a game server, bot on a VPS. If the clan counts and the wipe has a clock: split them. Then Node GC is not sitting next to map gen.

What we use at NexoraHost

Game servers from Frankfurt, CPU and RAM in the panel, no slot limit. The Discord bot runs next to that on a V-Server — cheap, isolated, reboots on its own. The Rust wipe checklist is already up; if you insist on one box, you need reserve, not hope.

Order a game server → V-Server for bots · Rust wipe 3 September
Out of memory · Monitoring · Rust · Backup