Game server hosting is sold by the slot, which is a unit that means almost nothing technically. Understanding what the number on the invoice is actually buying makes the difference between overpaying twice over and buying something that cannot run your game.
The slot is a billing unit, not a resource
"€0.60 per slot per month" is the standard shape of shared game hosting, and it is a pricing convention rather than a description of anything.
A slot does not correspond to an amount of CPU, memory or bandwidth. The host has decided that a 32-slot server of your game needs roughly a certain share of a machine, and priced accordingly. Two hosts charging the same per slot can be selling wildly different amounts of actual computer.
This is why slot pricing collapses as a comparison tool the moment your game is unusual. A 32-slot vanilla Minecraft server and a 32-slot heavily-modded one are the same number of slots and nothing like the same workload — and the second one will be throttled or unusable at the price the first is fine at.
The three tiers, and what actually differs
| Tier | Typical monthly | What you control | What bites |
|---|---|---|---|
| Shared / slot-based | €5–25 | Panel settings, configs, plugins | Noisy neighbours, no root, RAM caps |
| VPS | €10–60 | The whole operating system | You are the sysadmin |
| Dedicated | €60–200+ | The whole machine | You are the sysadmin, expensively |
The jump that matters is the first one, and it is not about power. It is about whether you can install things. A shared plan that does not let you run an arbitrary binary is fine until the day your game needs one, and then it is a migration.
The second jump is mostly about isolation and single-thread performance. A dedicated box guarantees nobody else is competing for the core your tick is running on, which for a busy server is the specification that decides everything.
What the price is hiding
RAM caps on shared plans. Frequently the real limit. A slot-priced plan advertising 32 slots may cap memory at a figure that a modded setup exceeds on startup, and the failure is a server that will not boot rather than one that runs slowly.
Bandwidth allowances. Rarely on the front of the listing, occasionally punitive. The monthly arithmetic puts a busy server well into the terabytes, and overage rates are set for people who do not read them.
CPU share. "Shared CPU" can mean a fair slice or a heavily oversubscribed one, and there is no way to tell from the listing. The tell is performance at peak: a plan that is fine on a Tuesday and stutters on a Saturday is oversubscribed, because everybody else is busy too.
Setup and migration fees. Uncommon but not extinct, and always in the terms rather than the price.
The renewal price. Introductory rates that double after the first term are standard in this market. The number to compare is the second-year price.
Location costs more than you think it should
The same specification in Frankfurt, Los Angeles and Singapore rarely costs the same, and the difference is bandwidth economics rather than hardware.
It is worth paying it. Latency is determined by physical distance and routing, and no amount of CPU compensates for hosting a European community in Texas. If your players are in one region, host there; if they are genuinely split, that is an argument for two servers rather than a compromise location that serves neither well.
DDoS protection: included, or sold back to you
Almost every host advertises DDoS protection. The differences are real and mostly undisclosed.
What matters is whether the protection is game-aware. Generic volumetric filtering stops a flood aimed at your address and does nothing about an application-layer attack that looks like legitimate query traffic. The second kind is what actually takes game servers down, and filtering it requires knowing what the protocol looks like.
Ask specifically. "Yes we have DDoS protection" is universal and uninformative.
When free is the right answer
A test server you rebuild weekly, a private world for six friends, or learning how any of this works: your own hardware costs electricity and nothing else, and it is the correct tool for all three.
The moment strangers depend on it, the calculus changes — not because home hardware is weak, but because a domestic connection and a public listing are a poor match.
What good value looks like
For most communities, in rough order of what actually returns the money:
- Correct region. Free to get right, impossible to compensate for.
- Single-thread performance. The tick budget is one core.
- Enough RAM with headroom. Especially modded; the failure is binary.
- Transfer allowance you will not exceed. Check it against real arithmetic.
- Root or console access. The thing you regret not having.
- Everything else.
Slot count is not on that list, because it is the thing you were sold rather than the thing you need. Decide how many players the game is good with — which is a design question, covered in how many slots to actually buy — and then find a plan that runs that well.
Testing before committing
Most hosts bill monthly and many offer a short refund window. Use it, and test the thing that will actually hurt:
- Run it at peak on a weekend, not at 3 a.m. on a Tuesday
- Fill it, or as close as you can — an empty server tests nothing
- Watch the tick rate under load, not the CPU percentage
- Check that a directory can see it, which catches query-side misconfiguration before it costs you a month of invisibility
A host that performs well empty and badly full is the most common bad outcome, and it is only detectable at load.
The short version
Slots are a billing convention. What you are actually buying is single-thread performance, memory headroom, a transfer allowance and a location — and only two of those are usually on the listing.
Compare the renewal price, not the introductory one. Test at peak with the server full. And decide your player count from what the game needs rather than what the pricing page suggested.
Published · 5 min read