Running several game servers on one box

One machine running four game servers is cheaper than four machines running one each, and it is how most small communities actually operate. It also fails in ways a single-server box does not, and the failures are all versions of the same thing: the servers cannot see each other, but they are competing.

They share one CPU, and the game does not know

Most game servers are effectively single-threaded for the part that matters. The main tick loop runs on one core, and no amount of additional cores makes that loop faster.

So four servers on a four-core box is not four servers with a core each. It is four main threads plus their support threads plus the OS, contending for four cores. Under light load it is fine. During a shared peak it is not, and the symptom is all four stuttering together for no reason visible in any one of them.

That is the tell worth memorising: simultaneous degradation across unrelated servers is a host problem, not a server problem. Nobody looks for it, because each server's own logs look normal.

Memory is the one that kills

CPU contention makes things slow. Memory overcommitment makes things disappear.

Allocate 6GB of heap to each of four servers on a 16GB box and the arithmetic does not work, but nothing fails until all four are busy at once, which might be a month later. Then the kernel picks the largest process and kills it, and the largest process is whichever server happened to be doing the most.

The one that dies is not the one that misbehaved. That is what makes this hard to diagnose from inside any single server, and it is the same silent termination described in container memory limits — no stack trace, no shutdown, just a log that stops.

Total all your heaps, add a gigabyte per JVM for overhead, add a gigabyte for the OS, and keep the sum comfortably under physical RAM. If that does not fit, you have three servers, not four.

Ports, and the collision that happens later

Each server needs a distinct game port and a distinct query port, and the second is where people collide. A game that defaults its query port to game-port-plus-one will silently overlap with a neighbour spaced only one apart.

Space them by ten. It costs nothing, it leaves room for a game that wants three ports, and it prevents the situation where one server's query answers for another, which presents as a listing showing the wrong information and is nearly impossible to reason about until you see the port map.

Write the port map down. It is the document you will want at 2am and the one nobody makes.

Disk is shared and invisible

Four servers writing logs, saves and backups to one disk contend on a resource with no per-process limit by default. A backup job on one server can stall the save on another, and the stall shows up as a lag spike with no cause in the game.

Stagger anything scheduled. If all four back up at 04:00, they are fighting; at 04:00, 04:15, 04:30 and 04:45, they are not. This is the cheapest fix on the list and it takes one edit per server.

Separate users, always

Each server should run as its own unprivileged user, with its own directory. Plugin code from strangers runs on all four boxes, and one compromised server should not mean four.

This costs nothing at setup and is effectively impossible to retrofit once everything is running as the same account with mixed file ownership. It is the same argument made in the security basics, and it matters more here rather than less.

The restart that takes everything down with it

The cost nobody prices when consolidating is that maintenance stops being per-server.

A kernel update, a full disk, a reboot after a provider migration: all of them hit every community on the box at once. Three servers on one machine is one outage affecting three sets of players, announced three times, and it lands on whichever evening the machine needed attention rather than on whichever evening each community could spare.

Staggering what you can helps. Game updates, plugin work and world maintenance can be done one server at a time. Anything at the level of the machine cannot, and that is the class of event worth mentioning when you tell people why the server is going down, because "the host is rebooting" explains a simultaneous outage in a way that three separate apologies do not.

When to stop consolidating

The honest threshold: when one server's peak reliably degrades another's, you have outgrown the box.

At that point the choice is a bigger machine or a second one, and the second machine is usually better — it removes the shared failure domain entirely, so a bad plugin on the Minecraft server stops being able to take down the Rust server. That is worth real money, and it is the argument that makes a dedicated box worth its premium once you are running more than a couple of things people care about.