A lot of game hosting gets sold on a single number. Gigabytes of RAM, or a vague "premium CPU". We think that's the wrong way to buy a game server. A fast CPU on an untuned OS, stuck in a throttled container, running conservative server software, will lose to a slower chip that someone actually thought about from top to bottom.
So this post walks the whole stack and explains why each layer is set up the way it is. No hand-waving. If you host with us, this is what you're running on.
It starts with not overselling
Every choice below rests on one rule: we don't sell capacity we don't have. A core we allocate to you is yours. RAM we promise is reserved, not "burstable if the neighbours happen to be quiet". That rule is also the reason the rest of the tuning is worth doing, because you can't tune your way out of a box that's carrying three times too many tenants.
Our resources are public and live on our Grafana and HetrixTools dashboards, so you don't have to take our word for any of it.
The hardware
Game server main loops (Minecraft's tick, Factorio's UPS, most simulation-heavy games) are single-thread bound and memory-latency bound. One thread has to finish this tick's work before the next tick can start, and it spends most of that time chasing pointers around the heap. Two things decide how well it runs:
- Per-core clock and IPC, which set how fast that one thread goes.
- Cache, which sets how often it stalls waiting on RAM.
So our fleet runs high-clock AMD Ryzen chips (Ryzen 7 and Ryzen 9), on the current Zen 5 generation as we retire the older parts. Cache is the reason to care: keeping a tick's hot working set resident cuts tick time (MSPT) more than extra clock speed does. That's also why a dedicated server can be specced with a large-cache X3D part, because on a cache-bound game more cache hits beat more gigahertz. On the shared game fleet we put the budget into clock speed and uniform cores instead, and that's the honest trade rather than a compromise: the extra L3 only pays off cleanly when the whole chip is yours, which is the one thing shared hardware can't give you.
Around the CPU we run:
- Gen4 NVMe in RAID 1. Chunk loads, world saves and database writes are all latency-sensitive, and cheap SATA SSDs stall the tick. RAID 1 also means a dead drive doesn't take your world with it.
- DDR5 at 5200 to 6000, so the JVM has headroom and garbage-collection pauses stay short.
- Real network capacity with DDoS protection, because the busier and more popular your server gets, the more likely it is to be attacked.
One thing we avoid on purpose is chasing thread count with efficiency cores. A chip with 8 strong cores and 16 weak ones looks great on a spec sheet and behaves badly for game servers: if the scheduler drops your tick thread onto a weak core, your TPS falls and nothing in your logs explains why. Uniform, full-power cores keep performance predictable, and predictable is what you're actually paying for.
The operating system
Every node runs Debian 13, and we build our own 7.x kernel for the fleet rather than taking the distribution's. It's live on the first nodes now and rolling out across the rest, and it exists so the latency work below is compiled in rather than fought for at runtime. A stock install is tuned for throughput and power saving, and a game server wants the opposite: the same low latency on every tick, for as long as the server is up. So we tune for that. We won't publish the exact config, but here are the levers we pull and the reasoning behind them. None of it is exotic. It's mostly unglamorous work that is easy to skip.
- CPU governor set to performance, so clocks aren't ramping up and down while the tick waits.
- Idle latency capped. Deep sleep states save power but add wake-up delay that shows up as tick jitter, so we trade a little power for a flatter frame time.
- Huge pages tuned for large JVM heaps. Done well they cut TLB misses and GC overhead. Done badly they add allocation stalls, so it's a deliberate setting rather than a distro default.
- Swap kept disciplined. A game server that swaps has already lost the tick, and since RAM is reserved anyway we don't lean on swap to cover for oversubscription.
- A short NVMe I/O path. On storage this fast the kernel's heavier I/O schedulers just add latency, so we get out of the way.
- A tuned network stack: modern congestion control, sensible buffers and connection limits, so a full server with a lot of plugins doesn't starve the socket.
- Tuned NICs, beyond a tuned stack. We adjust the network cards themselves with ethtool (ring buffers, interrupt coalescing, offloads), so packets reach your server with as little latency and jitter as we can manage.
- Generous open-file and process limits, so busy modpacks never hit a ceiling we could have raised.
- Cache and core locality respected, so a server stays on one set of cores and one cache domain instead of being bounced across the chip. That matters most on the larger multi-cache-domain parts, and it's the piece we're rolling out across the fleet right now: live on the nodes already converted, with the rest following.
Individually none of these is a trade secret. The point is that we actually apply them per node and then measure the result, rather than assuming a default is good enough.
Docker and the panel
Game servers run in containers, managed by our panel (Raw Power Panel, which is built on Pterodactyl). Containers give us clean isolation and near-instant provisioning. The catch is that their default settings quietly throttle game servers, so we change a few things.
- Real core time instead of a throttle. The lazy way to limit a container is a CFS quota, say "50% of a core", which pauses your process mid-tick the moment it hits the quota and produces lag spikes on an otherwise idle box. We give your server its own core time instead, pinned to a fixed set of cores rather than throttled against a percentage. That's the standard we're converting the fleet to: live on the nodes already done, rolling out on the rest, and it's the change we're spending this quarter on because it's worth more to your tick than any spec-sheet number on this page.
- Reserved memory with no surprise kills. Your RAM limit is backed by real reserved memory, with swap accounting set so a brief spike doesn't get the container OOM-killed. That's only possible because the box isn't oversold in the first place.
- Container storage on the same Gen4 NVMe, with nothing over the network in the hot path, so chunk I/O and world saves stay fast.
- A JVM heap sized to the plan, with room left for off-heap and GC, rather than handing Java everything and hoping.
- File-descriptor and process limits raised inside the container, so big packs don't trip a limit the host itself would never notice.
- No fighting over resources with neighbours, because the node isn't packed past its real core and memory budget.
It's the same idea as the OS layer. Containers give us safe isolation, and we undo the parts of the default config that were written for web microservices rather than latency-critical game loops.
The server software
Good hardware and a tuned OS give you a fast, quiet box. The last piece is the server software itself.
For Minecraft we recommend Paper or Purpur on plugin servers, and we help with heavy modpacks, including Create packs running hundreds of mods, on Forge, NeoForge and Fabric. It's the same theme as everything above. Paper moves chunk loading, generation and lighting onto worker threads, and modded servers get similar help from performance mods. On oversold shared hosting those threads fight other tenants for the same cores. On a dedicated box you own the whole chip, so the work lands on cores that are actually free, and the extra cache keeps the main tick fast. It's a measurable TPS gain rather than a theoretical one.
We'll also sort the less glamorous parts with you: tuned JVM flags, the right garbage collector and heap size for your plan, and sane defaults so your first boot isn't a research project.
(This is the overview. For the detail, see our guides on Paper vs Purpur and choosing a CPU for Minecraft.)
Why we're fine telling you all this
You'll have noticed we just handed over most of the playbook. We're relaxed about that, because the hard part was never the knowledge.
Every lever above is public. Any competent host knows to set the governor to performance, pin cores rather than throttle them, and run a performance fork on a dedicated box. You could copy the whole list this afternoon.
What you can't copy is the thing that makes it work, which is genuinely reserving the resources. All of this tuning assumes the box isn't carrying three times too many tenants. The moment you oversell, none of it holds. Pinned cores stop helping once they're contended, reserved RAM isn't reserved any more, and the tick jitters no matter how clean your sysctl is.
So the real advantage is the boring, expensive one. We buy the hardware, reserve the RAM, and don't sell it twice. That's the part a host built on overselling can't follow us into, because the overselling is their margin. The reserved RAM and the dedicated hardware turn out to be exactly what nobody undercutting us can afford.
One more admission while we are being candid. Most servers do not need the bottom half of this page. A ten player survival world on a quiet node runs perfectly well on far less care than we take, and we are not going to imply otherwise. It is overkill. The tuning is a one-off cost on hardware we already own, and what it buys us is an afternoon we never spend arguing about whose fault the lag is.
Every layer here is pointed at one outcome: the tick lands on time, and the resources you paid for are actually there. If you want to check, the dashboards are live rather than a screenshot. And if you're running something unusual and aren't sure the stack fits, ask us in Discord. We like those questions.