Game server hosting on bare metal

A dedicated game server on bare metal is a physical machine that runs your game processes straight on the CPU, with no hypervisor in the way and no other tenant competing for the same cores. You get every clock cycle the chip can produce and full root to install whatever the game needs.

That matters more for games than for most workloads. A game tick has a fixed deadline: at 20 ticks per second a Minecraft server has 50 milliseconds to simulate the whole world before the next tick, and one thread does most of that work. Shared or virtualised hosting hands you a slice of a core and a neighbour who can steal it at the wrong moment. Bare metal removes both variables.

New to running your own game boxes? Read our guide to running game servers on bare metal.

Why bare metal beats a VM for game servers

The bottleneck in almost every game server is single-thread CPU performance. The main simulation loop, physics, entity ticks and world generation run on one core, and adding more cores does nothing for it. What helps is a higher clock and a CPU that is not sharing its cache and memory bandwidth with anyone else.

A virtual machine gives you neither guarantee. The hypervisor schedules your vCPU against other guests, boost clocks are capped or hidden, and a noisy neighbour saturating memory bandwidth shows up in your game as stutter and dropped ticks even while your own CPU graph looks idle. On bare metal the clock is yours, the cache is yours, and tick times stay flat under the same load.

• Full boost clock, held under sustained load rather than throttled to a shared ceiling
• No steal time: the scheduler never pauses your simulation to run someone else’s VM
• Cache and memory bandwidth dedicated to your processes, so frame and tick timing stay predictable
• Root access to pin threads, tune the kernel, and set the CPU governor to performance

What the hardware suits

This is unmanaged bare metal. You install and run the game servers yourself; we hand you the machine, the network and root. The high-clock configurations map cleanly onto the games people actually host:

• Minecraft networks, from a single Paper server to a Velocity or BungeeCord proxy fronting a dozen backends
• Survival and sandbox titles like Rust, ARK: Survival Ascended, Valheim and Palworld, which lean hard on one fast core per instance
• Competitive shooters such as CS2, where tick and subtick timing depend on the CPU finishing each frame on schedule
• Panels like Pterodactyl and its Pelican fork, which turn one box into a self-service host for many game instances

Unmanaged, and that is the point

None of these are things we run for you. They are what a fast single-tenant box is good at, and having root means you install the exact versions, mods and panels you want, on your own schedule, without a control panel deciding it for you.

Picking a CPU for game servers

Start from clock speed. The AMD Ryzen 9950X and 7950X both boost to 5.7GHz, as fast as anything we stock, which is why they head the list above. Sixteen cores is plenty to run several instances side by side; the clock is what decides how each one feels to the players on it.

The many-core EPYC parts are the wrong tool here. A 32-core EPYC 9354P wins on aggregate throughput for containers or databases, but each individual core is slower, so a single busy game server runs worse on it than on a Ryzen. Reach for high core count only when you are packing dozens of small instances and no single one is CPU-bound.

Pair the CPU with enough RAM for your instance count and NVMe for fast world and chunk I/O. A dozen modded Minecraft servers want far more memory than one vanilla world, so size RAM to the instances you plan to run rather than to the core count.

Network, latency and staying up under attack

Latency is geography plus routing. A server in the wrong region adds round-trip time that no amount of CPU can claw back, so put the box near the players: for a European player base that means our Amsterdam location. Check the real path yourself from our looking glass before you commit.

Everything runs on our own network, AS55285, with always-on DDoS mitigation inline in front of the public interface. Game servers are a common target, and the profiles here are built to keep UDP game ports answering through a volumetric flood rather than blackholing your address to protect everyone else. You control the firewall and mitigation rules yourself, so opening a port range for a new game or tightening one during an attack does not wait on a support ticket.

Private networking for multiplayer topologies

A multiplayer network is rarely one machine. Private networking between your servers lets you sit a proxy, a Velocity or BungeeCord front for Minecraft, on the public interface and keep the backend game servers on a private segment players cannot reach directly. A customer DMZ exposes only the proxy while replication, RCON and backend traffic stay off the public internet entirely.

Reimaging and netbooting between deployments

Because provisioning is sub-minute, a box is disposable in the useful sense: wipe it and redeploy a clean image between game deployments, or use a custom iPXE configuration to netboot a prepared image with your panel and game files already baked in, including a diskless RAM-only root if you want nothing written to local storage. For anything else bootable, ISO mounting over the KVM console lets you install by hand and watch it come up.