Game Server Hosting on Bare Metal: Why Dedicated Hardware Wins

Answer first: why bare metal wins for game servers

A game server is not a web server. It runs a single simulation loop that steps the whole world forward on a fixed clock: physics, entities, players, everything, in order, on one thread. Minecraft runs that loop 20 times a second, which gives it 50 milliseconds to finish each tick. Miss the deadline and the tick runs long, the server falls behind, and players feel it as rubber-banding, delayed hits and lag spikes. So the numbers that decide whether a game server feels good are per-core speed and timing consistency, not core count or throughput.

That is the whole case for bare metal in one paragraph. A shared VPS puts a hypervisor's scheduler between your tick loop and the physical CPU. When a neighbour on the same host gets busy, your thread waits for its turn, and that wait lands as jitter right when a tick needs to finish on time. Bare metal gives you the entire machine, with nothing scheduling the CPU out from under you. For a friends-only server that sits idle most of the day, none of this matters and a VPS is fine. For anything with a full player count and a tight tick budget, the physical machine wins because it removes the one thing a tick loop cannot tolerate: someone else deciding when it gets to run.

This article covers:

• what "bare metal" means next to a VPS and a managed game-server panel
• why a game-server workload behaves differently from the web apps most hosting advice is written for
• why high clock speed beats core count for most titles, and the cases where many cores earn their place
• how much RAM popular servers actually need, with the public figures for each
• storage, backups, and the DDoS reality of putting a game IP on the public internet
• running a control panel like Pterodactyl or its Pelican fork on your own hardware
• the honest list of times you should not bother with bare metal

For the deeper timing argument, two companion pieces go further than this overview: bare metal versus virtual machines puts numbers on the gap, and why latency matters for game servers covers the network side.

What "bare metal" actually means

There are three ways to run a game server, and the difference between them is who controls the CPU.

Managed game-server hosting. You rent a slot for one game, the provider runs the hardware and a control panel, and you get a web page with a start button and a config editor. It is the fastest way to get a server live and the least you will ever have to think about the machine. You also get whatever CPU, RAM and network the provider decided a slot should have, on hardware shared with other customers' slots.

A VPS. You rent a virtual machine: a slice of a physical host, carved out by a hypervisor such as KVM or VMware, or by a container layer such as OpenVZ or LXC. You get root and can install anything. What you do not get is the whole CPU. The host's scheduler hands your virtual cores real cycles when they are free, and "when they are free" depends on what every other tenant on the box is doing.

Bare metal. You rent the entire physical server. No hypervisor, no other tenants, no scheduler deciding when your process runs. The clock speed on the spec sheet is the clock speed your tick loop gets, all the time. You also own everything else that comes with a real machine: the full RAM, the NVMe, the network port, and the patching and backups a managed host would otherwise have handled.

The reason this split matters more for games than for most workloads comes down to that scheduler, and to how a game server uses a CPU in the first place.

Why a game-server workload is unusual

Most server workloads are throughput machines. A web server handles a thousand independent requests across every core you give it; a database spreads queries over connections. Add cores and they go faster. A game server does the opposite. It advances one shared world state in strict order, because where entity B moves this tick depends on where entity A moved this tick, so the work cannot be split across cores without the simulation disagreeing with itself. Most game servers therefore run their main loop on a single thread and lean on a handful of extra threads only for side jobs like networking, chunk generation and file I/O.

That single loop runs against a deadline. Minecraft's 20 ticks per second is a 50 ms budget per tick; other engines pick their own rate, but the shape is the same. When a tick's work fits inside its budget, the server holds full tick rate and the world feels responsive. When it does not, the tick overruns, the next one starts late, and the server either drops to a lower effective tick rate or piles up lag until it catches up. Players read that as hit registration going wrong and entities teleporting. The metric that predicts it is not average CPU load. It is the worst-case time to finish a tick, and worst-case timing is exactly what a shared scheduler makes unpredictable.

Two more traits stack on top:

• Latency sensitivity. A tick that finishes on time is wasted if the packet takes 120 ms to reach the player. Game servers care about round-trip time and route quality far more than about raw bandwidth, which is why datacentre location and network peering matter as much as the CPU. The latency article works through the round-trip budget by genre.
• Bursty CPU. Load is not steady. A raid on a Rust base, a redstone contraption firing, forty players landing in one spot at once: the tick that has to simulate all of it is the one that blows the budget. You size for the spike, not the average.

Jitter, not throughput, is the enemy. A server that finishes every tick in 20 ms except for one 80 ms stall a minute feels worse than one that steadily takes 35 ms, because the stall is the moment a player gets shot from behind cover. This is the biggest single reason shared tenancy fights against game workloads, and it is the subject of bare metal versus virtual machines.

Clocks beat cores, until they don't

The practical takeaway from that single-threaded loop: for one game server, a CPU with fewer, faster cores beats one with many slow cores every time. Our server sizing guide puts it bluntly, that sixty-four slow cores lose to eight fast ones, and calls it the most common game-server sizing mistake. A modern chip past 5 GHz with strong per-core performance, like the Ryzen 9950X on our game-server configs at 4.3 GHz base and 5.7 GHz boost, finishes a heavy Minecraft or Rust tick sooner than a 64-core server platform clocked at 2.5 GHz, no matter how many cores the big chip carries, because the loop can only ever use one of them at a time.

Cores are not useless, though. They pay off the moment you stop running one server and start running many:

• Multiple instances. Ten Minecraft servers, or a Rust server plus an ARK cluster plus a few Valheim worlds, are ten-plus independent single-threaded loops. Now core count is throughput again: each instance gets its own core or two and they run in parallel.
• A control panel. Running Pterodactyl or AMP to host many game servers on one box is the many-cores case by definition; more on that below.
• Side work. Even a single server uses extra threads for chunk generation, compression and backups. Headroom beyond the main core keeps those off the critical path.

So the rule is short: fast cores for one server, more cores for many. High clock is the default, and core count is what you add when the machine's job is to run a fleet rather than a single world.

How much RAM popular servers actually need

RAM is where public numbers exist, so here they are, drawn from each game's own guidance and the operator consensus around it. Treat them as per-instance figures, and remember that plugins, mods and player count push every one of them up.

The Minecraft figures come from how the Java server uses memory. PaperMC's tuning guidance recommends running with Aikar's flags, a set of G1 garbage-collector arguments, and setting the initial and maximum heap to the same value so the JVM never resizes mid-tick. Its own note is worth repeating: a well-tuned 6 GB heap out-performs a badly-tuned 12 GB one, so more RAM is not automatically more performance here. View distance is the multiplier nobody expects, because every increment loads more chunks per player and raises both the RAM and the per-tick cost.

Counter-Strike 2 is the light one on memory and the demanding one on timing. A clean server sits around 2.5–3 GB and climbs past 6 GB once you add plugins, custom workshop maps and a full 64-slot roster. It is bound by its tick loop and per-core speed, not by RAM. Valve describes CS2 as a 64-tick server with a "subtick" input layer that timestamps each shot and movement to the exact moment it happened, independent of the tick, which puts even more weight on the server finishing its work predictably; the description is on Valve's Counter-Strike 2 page.

Then the heavy end. Palworld's official requirements recommend 16 GB, note that 8 GB "is also bootable, but increases the possibility of server crashes due to out of memory," and point to 32 GB for larger servers. Operators widely report that its memory use climbs the longer the server runs, and the standard workaround is a scheduled restart every several hours. ARK: Survival Ascended is heavier still; community reports put the server binary at 6–10 GB before anyone connects, 16 GB as a single-map minimum, and 12–18 GB on top for each extra map in a cluster. Rust sits in between at 8–16 GB depending on map size and population, and, being a Unity server, is as clock-bound as it is RAM-bound. Valheim is the gentle one: its own documentation lists a 2 GB minimum, though 4–8 GB is the comfortable figure for a small group on a long-running world.

Two rules cover all of them. Size for the busy evening, not the empty afternoon; and leave headroom, because a game server that runs out of RAM does not slow down gracefully, it crashes or gets killed by the kernel mid-session. The sizing guide works through the headroom maths in general terms.

Storage: NVMe, world saves and backups

A game world is a store of chunks or regions that the server reads and writes constantly as players move through it. On a spinning disk, that random I/O becomes the thing players feel when a new area stutters as it loads. NVMe is the answer, and for a game server it is not a luxury. Chunk loading, world saves and player-data writes all land on or near the tick path, and NVMe's random-read latency is a different category from SATA SSDs, let alone hard drives.

World saves are the part people underestimate. A busy Minecraft or Rust world can grow to tens of gigabytes, and the periodic save writes a large slice of that to disk. On a slow disk the save itself causes a lag spike; on NVMe it finishes fast enough to stay off the critical path. Palworld's own documentation makes the blunt version of the point, warning that low-performance storage "may corrupt saved data."

Backups are separate from the fast disk and not optional. A world is one bad shutdown away from loss, and a griefed or rolled-back world is a restore, not a repair. The discipline is simple to state: frequent snapshots, kept somewhere that is not the same drive, tested at least once so you know the restore actually works. Off-box backups also cover the failure the fast NVMe cannot, which is the drive itself dying. RAID 1 across two NVMe drives keeps you running through a single drive failure, but it is not a backup, because it faithfully mirrors a deletion or a corruption to both drives at the same instant.

Network and the DDoS reality

Put a game server on a public IP and you have published a target. Game servers attract denial-of-service attacks more than almost any other workload, for a specific reason: the players know the IP, the games run over UDP, and a rival, a banned cheater or a booter-for-hire can point a flood at it with no skill required. UDP floods are the common shape, because UDP has no handshake to rate-limit and the traffic is easy to spoof and amplify.

This is where a home connection or an unprotected VPS falls over. A consumer line has neither the capacity to absorb a flood nor any upstream scrubbing, so the attack saturates the link and every player drops, whether or not the server process is even touched. Mitigation has to happen in the network in front of the server, where there is enough capacity to soak up the volume and filtering to drop the bad packets while the game's real UDP traffic passes through. The anatomy of these attacks and the defences against them is covered in DDoS attack types and protection.

Two practical notes. Game-aware filtering matters, because generic DDoS rules that work for a website can break a game: a UDP flood filter has to understand what legitimate game traffic looks like, or it drops real players along with the attack. And the box still needs hardening at the host level regardless of upstream protection, because a flood is not the only threat to a public server; the Linux server hardening checklist is the first-hour baseline.

Running a control panel on your own hardware

Once you are running more than one or two servers, you will want a control panel instead of a pile of tmux sessions and shell scripts. Three are worth knowing.

Pterodactyl is the open-source standard. It splits into two parts: the Panel, a PHP web application that needs a database (MySQL 8.0+ or MariaDB 10.6+), a web server and ideally Redis; and Wings, the daemon that actually runs each game server inside a Docker container on the host. That Docker requirement is the detail that decides your hardware. Wings needs a Linux host that can run Docker, and Pterodactyl's own docs note that container-based VPS types, OpenVZ, LXC and Virtuozzo, typically cannot run Docker at all; KVM is the one they guarantee. On bare metal the question never comes up, because you own the kernel.

Pelican is a fork of Pterodactyl, started in 2024, that relicensed the panel from the MIT licence to AGPLv3. Its FAQ is candid that it is still beta software as of 2026, so treat it as the fast-moving option: pick it if you want the newer development pace and can live with beta, and stay on Pterodactyl if you want the longer-settled build. Both follow the same panel-plus-daemon architecture and the same Docker requirement, so the hardware story is identical between them.

AMP, the Application Management Panel from CubeCoders, is the commercial alternative. It is paid, runs on both Linux and Windows, and trades the open-source licence for polish and support. If you would rather buy one supported product than assemble a stack, it is the one to look at.

All three turn a single dedicated server into a multi-tenant game host, which is the many-cores case from earlier made concrete. Each game instance is its own single-threaded loop, so a box running a panel wants both high clocks, so each instance's tick loop stays fast, and enough cores and RAM to run several of them at once without their loops fighting for time. Sizing the machine is a matter of adding up the per-instance RAM figures from the table above, plus a few gigabytes for the panel and the host, then picking a core count that covers your busiest instances all running at once.

When you don't need bare metal

Bare metal is the right tool for a full-population server on a tight tick budget. It is the wrong tool for plenty of real cases, and pretending otherwise would cost you money.

A VPS is the better call when:

• It is a few friends. Three to five people on a vanilla Valheim or a small Minecraft SMP put almost no load on the machine, and the odd millisecond of scheduler jitter is invisible at that scale. Valheim's 2 GB minimum runs happily on a small VPS.
• It is one light instance. A single low-population server for a game that is not CPU-hungry does not need a whole physical machine to itself. You would be paying for cores that idle.
• It is a test or dev box. Something you spin up, break and redeploy gains nothing from dedicated hardware. Cheap and disposable wins.
• It is spiky and mostly idle. A server that is empty most of the week and busy for one raid night is exactly the pattern a shared platform is priced for.

The crossover comes when the server is busy enough, often enough, that the tick budget starts getting tight; or when RAM needs cross the point where dedicated pricing beats an equivalent VPS tier; or when a public game IP needs real DDoS protection in front of it. Below that line, a VPS is not a compromise, it is the correct answer.

A quick decision table

Where each scenario lands, and the one factor that decides it:

Deploying on Serverside

A game server rewards the two things bare metal is good at: giving one process the whole, fast CPU, and sitting behind a network that can take a hit. A Serverside game-server machine runs on our own network (AS55285), with always-on DDoS mitigation in front of the public UDP port and filtering profiles tuned per game title, so the flood that would drop a home-hosted server never reaches the tick loop. The high-clock configurations, like the Ryzen 9950X, are chosen for exactly the single-threaded loop this article is about, and provisioning is sub-minute, so a fresh box is live before you have finished planning the world it will run.

If you are weighing hardware more broadly, the full dedicated server range and the sizing guide cover the rest, and picking a location close to your players is its own performance lever; our Amsterdam datacentre is the European anchor. Once the box is yours, the hardening checklist is the first thing to run on it.

FAQ

Do I need bare metal for a game server, or is a VPS enough?

It depends on load. For a few friends on a vanilla world, a VPS is enough and cheaper. Bare metal wins once the server runs a full player count on a tight tick budget, because a shared VPS puts a hypervisor's scheduler between your tick loop and the CPU, and that shows up as jitter exactly when a tick needs to finish on time.

Why does clock speed matter more than core count for a game server?

Because a game server runs its simulation loop on a single thread. The world steps forward in order, one tick at a time, and that work cannot be split across cores. A faster core finishes each tick sooner, while extra cores sit unused by the main loop. More cores only start to help once you run many instances, or a control panel that hosts several servers at once.

How much RAM does a game server need?

It ranges widely by title. Valheim runs on 2 GB, a Paper Minecraft server on 3–4 GB for a small group, Rust on 8–16 GB, and both Palworld and ARK: Survival Ascended on 16 GB or more per instance. Size for a full server on a busy evening and leave headroom, because running out of RAM crashes a game server rather than just slowing it down.

Can I run Pterodactyl on a VPS?

Only on the right kind. Pterodactyl's Wings daemon runs each server inside a Docker container, and container-based VPS types like OpenVZ and LXC usually cannot run Docker at all. A KVM VPS works, and a dedicated server always works because you own the kernel. If you plan to host many servers behind a panel, bare metal is the natural home for it anyway.

Do game servers really get attacked with DDoS?

Yes, more than most workloads. Players know the IP, the games run over UDP, and a flood needs no skill to launch. A home line or an unprotected VPS saturates and every player drops. Mitigation has to sit in the network in front of the server, with the capacity to absorb the volume and filtering that can tell game traffic apart from an attack.