What Game Hosting Means for Multiplayer Studios

Game hosting and web hosting share a name and almost nothing else.

A web server handles requests, returns responses, and idles between them. Latency in the hundreds of milliseconds is inconvenient. The statefulness of a session lives in a database somewhere. If a pod restarts, the next request goes somewhere else and the user probably does not notice.

A multiplayer game server doesn’t work like that. It is continuously running a physics simulation, processing player input, ticking state forward at a fixed rate, and pushing updates to every connected client, all in real time, simultaneously. Latency in the tens of milliseconds is visible. The statefulness of a session lives in memory, on that specific server. If it restarts mid-match, everyone in that match knows immediately.

That difference in behaviour is why game hosting is its own infrastructure category and why treating it like web hosting is a reliable path to problems.

What Game Servers Actually Need

Three requirements separate game server hosting from generic web hosting in practice.

Real-time tick processing. A game server runs a game loop that advances state on a fixed schedule, typically between 20 and 128 times per second depending on genre. Every tick consumes CPU regardless of whether players are connected. The host needs to guarantee consistent, low-jitter compute, not just average throughput. Hypervisor scheduling overhead and noisy-neighbour effects on shared cloud VMs introduce exactly the kind of unpredictable variance that breaks tick-rate consistency.

Low-latency UDP handling. Most real-time game traffic runs over UDP. It is stateless, fast, and unordered by design. It is also invisible to network infrastructure that expects TCP handshakes and connection state. A hosting layer that does not understand UDP is a hosting layer that cannot protect against UDP-based DDoS traffic, cannot route game packets efficiently, and cannot make per-player network decisions at the edge.

Per-session lifecycle management. Game server instances are created, allocated to a match, run until the session ends, and then cleaned up. This is a fundamentally different lifecycle from a long-running web service. The hosting platform needs to pre-warm servers before demand arrives, allocate them to sessions on request, and reclaim them when the session closes. Platforms that were designed for stateless services handle this lifecycle awkwardly, if at all.

Why Density Matters for Game Hosting

The compute requirements above mean that game hosting economics are driven by how many server instances you can run per node without compromising isolation or performance.

On GameFabric's Nitrado-owned bare metal, that figure is up to 150 game server instances per node, running on dedicated physical hardware with no hypervisor overhead and no virtualisation layer competing for scheduling cycles. On cloud nodes, the figure is up to 100 per node. The difference is not marketing; it is the absence of a virtualisation layer between your game server binary and the CPU it runs on.

For predictable, sustained player populations, bare metal handles baseline load at the higher density and lower per-session cost. Cloud capacity absorbs bursts. Region Types enforce the priority: bare metal fills first, cloud takes the overflow.

The Right Infrastructure for Your Game

If you are running a real-time multiplayer title, the infrastructure decisions that matter most are not the ones that web hosting solved years ago. They are the ones that are specific to your tick rate, your session model, and the latency requirements your players will actually notice.

Looking for game server hosting built around these requirements? Read how GameFabric handles server orchestration or talk to the team about what your game's infrastructure actually needs.