Choosing a Host: The Six Questions That Decide It

Every hosting page is the same page. A CPU model in small type, a memory figure in large type, a location list, "DDoS protection included", and a price that looks competitive because the comparison is doing the work.

Six questions get you past all of it. None of them is answered on the marketing page, and every one of them is answerable by email before you spend anything.

1. What is the single-core clock speed?

Not the core count. Game servers run their world simulation on one thread, so the fastest core you can get is the specification that determines how the server feels.

Providers publish the CPU model, which is enough, look up the boost clock. Above about 4.5 GHz on a recent generation is comfortable. Around 2.4 GHz is a throughput part built for many small workloads, and it will disappoint on a game whatever else the page claims. More cores will not fix your server is the full argument.

If the page does not name the CPU at all, that is the answer to the question.

2. Are the cores shared or dedicated?

"4 vCPU" on a VPS may be four threads on hardware shared with a dozen other customers. On a quiet host that is fine. On an oversold one your tick budget depends on what somebody else is doing, and the symptom is a server that is fine for a week and stutters on Thursday evenings for no reason you can find.

Ask directly whether cores are dedicated and whether the host oversells. The answer, and how readily it comes, both tell you something. Dedicated versus VPS covers the trade.

3. What kind of disk, and is IO limited?

NVMe against SATA SSD is a real difference on any game that saves a world, and some providers cap IO operations per second on cheaper tiers without saying so on the page.

The symptom of an IO cap is a periodic freeze that correlates with autosave. It is easy to misdiagnose as a memory problem and it is not fixed by more RAM. Disk speed matters more than you think covers it.

4. What happens during a DDoS, exactly?

"Protected" is not an answer. The useful questions are what the filtering capacity is, whether it is always on or engages on detection, and: the one that matters most, whether they null-route you above a threshold and for how long.

A provider whose response is a two-hour null-route has protection that ends with your server offline. What DDoS protection buys you covers asking properly.

5. Where are your players, and what is the route?

Not where the datacentre is. What the path from your players to it looks like.

Latency is determined by routing rather than distance, and two providers the same distance away can differ by 60 ms because one has a direct path and the other goes via somewhere unhelpful. Why routing beats distance explains the mechanism.

Test before committing. Most hosts publish a test IP or a looking glass. Ping it from your own connection and, more importantly, get the player furthest from you to ping it, theirs is the number that constrains the decision. Playing with friends in another region covers the group version of the same problem.

Check your own peak-hours chart first if you already run a server. Owners routinely host near themselves and then discover their community's peak is in a different timezone entirely.

6. What is the actual monthly cost?

Compare the whole thing, not the headline.

Backups billed separately. DDoS protection as an add-on tier. A panel licence. Bandwidth overage. A setup fee. Windows licensing folded into a higher price on the same hardware; Windows or Linux covers where that difference comes from.

What a game server costs to run works through the categories. The point of doing it is that the cheapest headline is frequently not the cheapest bill.

Managed, unmanaged, or a box

Three shapes, and the right one depends on what you want to spend time on.

A managed game host gives you a panel and handles the operating system. You pay more per unit of performance, you learn less, and you do not spend evenings on system administration. For somebody who wants to run a community rather than a machine, this is the correct answer and it is frequently framed as a defeat.

A VPS or dedicated box gives you control and a much better price per unit of performance, at the cost of doing everything yourself: keeping it running, security, backups, updates.

A box plus a panel is the middle: Pterodactyl or similar on hardware you rent, which gets you most of the convenience with none of the markup and one more thing to keep patched.

The things that are not worth paying for

More memory than the server uses. The most-sold and least useful upgrade. RAM and Java flags covers why more is frequently worse.

Core counts you cannot use. See question one.

"Premium" network tiers without a route test. Marketing language, occasionally real, testable in two minutes.

Uptime guarantees. Read what the remedy is. It is nearly always a partial credit on the month, which does not buy back the evening your players could not connect.

Before you commit

Take the shortest term available first. Monthly rather than annual, even at a worse rate. A year is a long time to be wrong about a route.

Run it for a fortnight in parallel if you are moving rather than starting. It costs one month's fee and it is the difference between a migration and an outage, moving a server between hosts covers the sequence, including the DNS work that has to start a week early.

Ask one support question before you buy. Anything, even something trivial. The reply time and the quality of it are the most reliable signal on this entire list, and it is the only one you can measure without spending anything.

The provider's answers are the test

None of the six questions is difficult. What makes them useful is that asking them is itself a measurement.

A provider who answers with the CPU model, the oversell policy and a null-route threshold in two sentences is a provider whose support will answer you at three in the morning when something is wrong. One who replies with marketing copy about enterprise-grade infrastructure has told you what their support is like, at no cost to you, before you have spent anything.

That is the highest-value signal available and almost nobody uses it. Hosting is a service, the hardware is roughly interchangeable at any given price, and the thing that will differ over a year is whether there is a competent person on the other end when your server is down and you cannot work out why.

The mistakes that cost the most

Committing annually for the discount. A year is a long time to be wrong about a route, and the discount is usually two months against being stuck for twelve.

Choosing on the memory figure. It is the easiest number to compare, which is exactly why it is the one advertised. RAM and Java flags covers why more is frequently worse rather than merely unnecessary.

Choosing the nearest datacentre. Geography is not latency. Test the route.

Migrating without a parallel period. One month of double billing is cheap against discovering the new host is worse after you have already left the old one.

Not asking about backups. Whether the host takes them, where they live, how long they are kept, and whether a restore costs anything. Most providers have an answer and most customers never ask until the day it matters. Game server backups covers doing your own regardless, which is the only version you control.

When to move, and when not to

Moving host is a day of work and a real risk of losing players, so it is worth being clear about what justifies it.

Worth moving for: repeated unexplained downtime, a route that is bad for most of your community, hardware that cannot keep the tick budget after you have ruled out plugins, or a provider whose support does not respond.

Not worth moving for: a slightly better price, a bigger memory allocation, or a performance problem you have not profiled. Most servers that feel slow are running something badly rather than running on the wrong machine, and profiling before purchasing is free.

If you do move, the migration sequence matters more than the destination: particularly the DNS work, which has to start a week before the move rather than on the day.

One last thing

Whatever you conclude from the above, test it against your own numbers rather than against advice. Every server is a specific game, on specific hardware, with a community in a specific timezone, and general guidance is wrong at the edges for all three reasons.

The measurements that settle most arguments are free and take minutes: the tick budget, the per-core load, the peak-hour shape, and the route from the player furthest away. Owners who take those four regularly make better decisions than owners who read more, and the gap is not close.