field notes · june 2026
Dedicated Box, VPS, or Cloud for a Game Server in 2026: The Honest Decision Tree
Every week someone asks the same thing in a different way. Should I rent a dedicated box, get a VPS, or just spin something up in the cloud? The honest answer is a short decision tree, and most of it comes down to one stubborn fact about how game servers actually run.
The question behind the question
The threads come back like clockwork. "Anyone here still running dedicated servers instead of VPS or cloud?" "Moving from a non-dedicated setup to a dedicated server, how do I choose?" "Before I go and rent an expensive dedicated box (I am a noob), is it even worth it?" The phrasing changes, the underlying anxiety does not. People sense that the three tiers are genuinely different, they just cannot see why from the spec sheets, because the spec sheets are written for web apps and databases, not game worlds.
So let us throw out the marketing vocabulary and reason from how a game server behaves. A game server is not a web app. It does not sit idle waiting for requests and then fan out across cores. It runs a relentless loop, several times a second, that has to finish on time or the world stutters. Once you internalise that, the choice between a dedicated box, a VPS, and hourly cloud stops being about price-per-month and starts being about whether your hardware can hit that deadline, every tick, for as long as the world needs to stay up.
The one fact that decides most of it
This site has banged this drum before and will keep banging it: most game simulation loops are single-thread bound. The hot loop, the one that updates every entity, runs the physics, ticks the AI, and resolves the world state, overwhelmingly runs on one core. Extra cores are useful, but they go to networking, to writing saves in the background, to running a second or third server instance beside the first. They do not make that one hot loop go faster.
The consequence is blunt. For a game server, raw single-core clock speed and dedicated cores beat a big vCPU count. A box advertising eight slow shared vCPUs will hold a busy world worse than a box with four fast, dedicated cores, because the world only ever leans on one of them at a time and it wants that one to be quick. When you compare hosts, look past the vCPU number to the per-core clock and the chip generation. That single number tells you more about how your tick rate will hold up than almost anything else on the page.
This is also why "it has loads of RAM" is a weak headline for a game server. RAM keeps the world resident and stops you swapping to disk, which matters, but no amount of memory rescues a sim loop that is starved of fast CPU. Size RAM to the game and the mod load, then spend your real attention on the cores.
Tick stability and the noisy neighbour
Single-thread speed is the ceiling. Tick stability is whether you actually reach it, tick after tick, and this is exactly where the three tiers separate.
On a dedicated or bare-metal box, the CPU is yours. Nobody else is on it. When your tick loop wants a core for a few milliseconds, it gets the core. The result is boringly steady tick rate, which is what you want.
On a VPS, you are sharing a physical host with other tenants, and that is fine right up until it is not. The failure mode has a name: CPU steal time, the slice of time your virtual machine wants to run but cannot, because the physical host is busy serving someone else. For a web app that is invisible. For a game server, whose tick loop has a hard deadline several times a second, stolen cycles land directly as lag, rubber-banding, and dropped ticks. A quiet, fairly-provisioned VPS will never show it. An oversold one, where the provider has packed in more tenants than the host can comfortably feed, will hand you a tick graph that looks fine at 2pm and falls apart when a neighbour's batch job spikes at 2am. You can watch for it: the steal metric in top creeping up is the tell that the host is oversold and your tick rate is paying for it.
Hourly cloud instances sit in between and depend entirely on what you buy. A small shared "burstable" instance behaves like an oversold VPS once you exhaust its CPU credits, sometimes worse, because the throttling is abrupt. A larger dedicated-CPU cloud instance behaves like a dedicated box, at a dedicated-box-or-higher price. The cloud does not magically solve the noisy-neighbour problem; it just lets you pay to opt out of it, by the hour.
Game worlds are stateful, and cloud forgets that
There is a second fact that quietly rules out the most-hyped option for the most-common case. Game worlds are stateful. The world is a save file that grows and changes and must persist, and players expect to reconnect to the same world tomorrow, not a fresh one.
Cloud's whole pitch is elasticity: spin up when you need compute, tear down when you do not, pay only for what you use. That is a beautiful fit for stateless, bursty work. It is an awkward fit for a thing that has to stay up continuously and remember everything. If your game world needs to be reachable around the clock, an always-on cloud instance throws away the pay-for-what-you-use advantage entirely, and you are now renting a VPS-or-dedicated equivalent through a meter that is optimised for the opposite usage pattern. Worse, the meter has edges the spec sheet downplays: egress charges for data leaving the instance, which a chatty multiplayer server generates constantly, and per-GB block-storage fees for the disk holding a world that only grows. None of these are dealbreakers in isolation. Together they make a persistent cloud game server quietly more expensive and far less predictable than the fixed monthly number on a box.
Where cloud genuinely shines is the inverse case: a server that is supposed to be ephemeral. A weekend tournament. A launch-week rush you expect to fade. A scheduled event where you size up hard for two days and tear it all down on Monday. There, paying by the hour and discarding the instance afterwards is exactly right, and the elasticity you would have wasted on a forever-world becomes the whole point.
The decision tree
Strip it down to three honest profiles and the choice mostly makes itself.
The branches in plain language. If you are a small group who play together a few evenings a week and the world is light, start on a VPS, ideally one with dedicated or at least fairly-provisioned fast cores rather than the cheapest oversold tier. If your tick rate suffers, you are watching steal time climb, or your player count and mod load have outgrown a shared instance, move up to a dedicated box and stop sharing a CPU. And if the whole thing is genuinely temporary, an event with a start and an end date, reach for hourly cloud and bin it when the event is over. The mistake is using cloud for a forever-world or a dedicated box for four people on vanilla. Those are the two ends of getting it wrong.
The traps in each tier
Each tier has a characteristic way of disappointing you, and knowing them up front is half the decision.
The VPS trap is steal time on an oversold host. A VPS can be a fantastic deal or a quiet disaster, and the price tag rarely tells you which. The same nominal specs can hide a generously-provisioned host or a packed one. You only find out under load, often at the worst time. The defence is to favour providers that offer dedicated vCPU rather than burstable shared cores for anything that needs steady ticks, and to actually watch the steal metric once you are running. If it is consistently non-trivial, no config tweak will save you; the host is the problem.
The cloud trap is the always-on bill and the egress meter. Cloud pricing is built to reward bursty, stateless work and to gently punish always-on stateful work. Leave a game server running on a metered instance for a month and the headline hourly rate quietly compounds, then the egress and storage line items arrive to finish the job. Cloud is not expensive because it is bad; it is expensive when you use it against its grain. A persistent world is against its grain.
The dedicated trap is paying for capacity you never touch. A dedicated box is the right tool for a demanding world, and the wrong tool for four friends on a vanilla map. People reach for it because "dedicated" sounds serious and safe, then run a server that uses a fraction of one core and wonder why they are paying for eight. Overkill is a real cost, not a free safety margin. Match the tier to the actual load, and only climb when the load makes you.
The cheapest mistake is buying the wrong tier confidently. Match the box to how the world will actually run, not to how impressive the spec sheet reads.
The honest bottom line
There is no universal winner, and anyone who tells you there is one is selling that tier. The right answer falls out of two facts about game servers that the generic spec sheets bury. The sim loop is single-thread bound, so fast dedicated cores beat a big vCPU count and noisy neighbours quietly eat your tick rate. And the world is stateful, so a thing that must stay up forever fits a fixed-price box far better than a meter built for bursts.
Run the tree. Small group on a light world, a VPS with fast cores is plenty and a dedicated box is waste. Busy community world where tick stability is the whole experience, pay for dedicated cores and stop sharing a CPU. Genuinely temporary, an event with an end date, let cloud do the one thing cloud is unbeatable at and then turn it off. Pick the tier that matches how your world actually behaves, not the one with the most reassuring name, and you will spend less and lag less than almost everyone asking the question.