Hosting game servers
Game hosting is one of the few workloads where the usual advice is wrong. More cores will not help you. A faster core will.
The tick loop decides everything
Almost every game server runs a single authoritative loop that advances the world state a fixed number of times per second — 20, 64, 128 ticks. That loop lives on one core. If it cannot finish its work inside a tick, the server stutters for everyone on it, no matter how many idle cores sit next to it.
So the specification is: the highest sustained single-core clock you can get, and enough cores to run several instances side by side without them interfering. See choosing a CPU.
Why virtualised instances disappoint
Steal time is fatal here. A few milliseconds of hypervisor scheduling delay is invisible to a web application and is a visible stutter in a shooter. On bare metal there is nothing between your loop and the processor; the frame you measure in testing is the frame players get on a Saturday night. That consistency, not raw speed, is what players notice.
See when a VPS stops being enough.
Latency and where to host
Players feel round-trip time directly. Amsterdam is one of the best-connected points in the world and sits within roughly 10–30 ms of most of western and central Europe, which is why so much European game hosting is here.
Test from where your players actually are before you commit, and if a particular network reaches us badly, tell us — routing is ours and we can often improve a path. See routing problems.
Bandwidth
Per player, game traffic is small. The problem is that it is constant, bidirectional and bursty at the wrong moments — map downloads, mod packs, a wave of reconnects after a restart. An unmetered port means a busy weekend costs the same as a quiet one, which is the right shape for this business.
DDoS is part of the job
Game servers are attacked more than almost anything else, often by players who lost. Every server we provide comes with DDoS protection against large attacks, absorbed at backbone level — see DDoS filtering.
What you should do on your side:
- Do not publish the machine's real address if you can front it with a proxy
- Rate-limit your query port; the status protocols of several games amplify
- Keep the game binaries patched — many “attacks” are application-level exploits, not floods
Practical tuning
- Pin instances to cores with
tasksetorCPUAffinity=in the unit file, so they stop migrating between cores. - Give each instance its own user and service — see running your application as a service.
- Watch the tick rate, not the CPU graph. Most game servers expose it; alert on it dropping below target. See monitoring.
- Disable the CPU power governor's economy modes so clocks do not drop during quiet moments and lag the first player back.
- Put world data on NVMe. Saves and chunk loading are latency-sensitive, and a save stall shows up as a freeze.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base