Choosing a hosting provider: what to look at, from the inside

When we pick a host, we look at six things, in this order: what CPU the workload actually lands on and how fast one core of it is, what every "unlimited" on the page turns into once the terms are read, whether the status page tells the truth on a bad day, who restores your data and how, how much of the machine you can reach without asking anyone, and whether a person answers when you write in. Price comes after all of that, because a cheap plan that fails on any of the six is not cheap.

We run the RE:NODE platform - the orchestration that provisions, scales and recovers customer servers, the game, VDS, web, database and storage lines, and the monitoring and backup automation around them. That gives us an uncomfortable view of how hosting is sold versus how it is run. Most of what follows is the stuff operators know and the plan page does not say. It applies to any host, including us, and some of it is deliberately unflattering to small providers like ours.

There is a shorter checklist version in choosing game server hosting. This one is the reasoning behind it.

Why the spec sheet lies by omission#

A plan page is written to be compared, so it lists the things that compare easily: gigabytes of RAM, gigabytes of disk, a number of cores, a price. None of those is false. The trouble is what they leave out, and from the inside we can tell you the omissions are not random.

RAM is easy to sell and easy to deliver honestly, because memory is either there or it is not. Disk size is the same. Cores are where it gets slippery, because "2 vCPU" says nothing about which CPU, how old it is, how fast one thread runs, or how many other customers are queued on the same physical cores. Bandwidth is slipperier still. And the things that decide whether you stay - backups, access, support, what happens at 3am - rarely appear on the plan page at all.

So the rule we ended up with is simple: the numbers on the page are the floor of what you need to know, not the answer. Everything below is about the questions those numbers do not answer.

CPU: generation and single-thread speed beat core counts#

This is the single most misunderstood thing in hosting, and it matters most for game servers.

Most game servers do their important work on one thread. The simulation tick - moving entities, running game logic, deciding what every player sees next - runs on a main thread, and the other cores help with networking, chunk loading, saving and the like. Minecraft is the famous example, but the pattern is broad: when a server lags, it is usually one core at 100% while the rest sit idle. We wrote that up properly in reading game server CPU usage, and game server CPU requirements covers it game by game.

What that means for choosing a host:

• A newer CPU at a high clock usually beats an older CPU with more cores. Per-clock performance has moved a lot between generations, so "3.0 GHz" on a CPU from many years ago and "3.0 GHz" on a recent one are not the same speed.
• Many-core server chips are excellent at running many things at once and often unremarkable at running one thing fast. That is the right trade for a host packing in web apps. It is the wrong one for a single busy game server.
• A "vCPU" is usually one hardware thread, not one physical core. Two vCPU may be the two hyperthreads of a single core, which is less than two full cores when both are busy.

The question to ask any host is "which CPU model does this plan run on?" A good answer names a model. A fair answer says "it varies by node, here are the models we use". An evasive answer - "enterprise-grade processors" - tells you they would rather you did not know. In fairness to hosts, not all of them can promise a model, because nodes get replaced. But they can tell you what is in the fleet today.

On RE:NODE, the VDS line names its CPU (the Intel i9-9900K), and on the shared lines the plan's CPU figure is a percentage of one core enforced as a hard limit - 250 means 2.5 vCPU of throttled share, not 2.5 cores you get to burst past. A server sitting at its limit is slow, never suspended for it. We do not publish a model for the shared nodes, so if that matters to you, that is a question to ask us too.

How to check what you actually got

On a VDS you have a shell, so look:

$ lscpu | grep -E 'Model name|^CPU\(s\)|Thread'$ sysbench cpu --threads=1 --time=30 run$ vmstat 1 10

The first line tells you the model and how many threads you have. The sysbench run with one thread gives you an events-per-second number you can compare between hosts - run it on every candidate the same way. In vmstat, watch the st column: steal time is CPU your virtual machine wanted and the hypervisor gave to someone else. A few percent now and then is normal on shared hardware. Steal that sits high while your own load is low means a crowded host, and shared CPU and noisy neighbours explains what you can and cannot do about it.

On a game panel you usually have no shell, but the host's /proc/cpuinfo is often visible from inside the container, and the console's CPU graph against the limit tells you whether you are bounded by the share you bought.

What "unlimited" means#

From the operator's side, nothing is unlimited. Every resource we work with has a physical ceiling: uplink capacity, disk throughput, inodes, power. When a plan says "unlimited", it means one of three things, and you want to know which.

"Unmetered" is the honest word for bandwidth: you are not charged per gigabyte. It is not a promise that you can saturate a shared uplink all month. Every host with an unmetered plan has a point at which someone's traffic starts hurting other customers, and the only real question is whether they tell you where it is and what happens when you reach it - a throttle, an email, a suspension. Our own wording is that unmetered means not billed per gigabyte, not a licence to saturate a shared uplink, and bandwidth and fair use goes into what that means in practice.

"Unlimited player slots" on a game server is the one that annoys us most, because it is technically true and practically meaningless. The game, the CPU and the RAM decide how many players fit, not a number in the panel. A host advertising unlimited slots on a small plan is selling a number you cannot use.

The test we apply: if a plan says unlimited, search the terms of service for "fair use", "acceptable use", "excessive" and "inode". Whatever the terms say is the real plan. If the terms say nothing at all, the limit exists anyway - it is just enforced by whoever is on shift, by judgement, without warning.

How to read a status page#

Every host has a status page now, and most of them are green almost all the time. That alone tells you very little. Here is what we look at instead.

1. Who measures it. A status page fed by automated checks from outside the host's network is worth more than one somebody edits by hand after the fact. A hand-edited page is green until a human decides it should not be.
2. How fine-grained it is. One "All systems operational" banner for an entire company hides the fact that your node can be down while everything else is up. Per-node or per-service components are more honest.
3. The history. Scroll back. A page with no incidents in a year is either describing a remarkably lucky operation or not being updated. Real infrastructure has bad days, and the honest pages show them.
4. What the incident notes say. "We are investigating" followed by "resolved" with nothing in between teaches you nothing. Notes that say what broke, what was affected and what changed afterwards tell you how the team thinks.
5. Where it is hosted. If the status page lives on the same infrastructure it reports on, it goes down at exactly the moment you need it.

On uptime percentages: they are only meaningful with the measurement interval and the definition next to them. 99.9% over a 30-day month allows about 43 minutes of downtime; 99.99% allows about four. If the check runs every five minutes, anything shorter than that may never be seen. And an SLA usually means a partial credit off your bill, not your downtime back - read what the remedy is before you are impressed by the number.

For what it is worth, RE:NODE's status page samples availability every five minutes and we do not publish an uptime percentage or an SLA. We would rather say that plainly than print a figure. You should weigh that the same way you would weigh it on any host.

Backups, and who restores them#

This is where we have the strongest opinions, because backup automation is a large part of running a platform, and because the gap between "we do backups" and "you can get your data back" is where most hosting disappointment lives.

There are two different things a host can mean by "backups":

• Platform backups - the host copies its own disks so it can recover the machine if hardware fails. You usually cannot see these, cannot choose what is in them and cannot restore a single file from them yourself. They protect the host's ability to rebuild, not your ability to undo a mistake.
• Customer backups - copies of your server that you can make, schedule, restore and download.

You want to know which one a plan includes, and you want the second kind. Then you want answers to these:

• Can I restore it myself, or do I file a ticket and wait?
• Can I download it, so a copy exists outside this host entirely?
• Where is it stored? A backup on the same disk as the data it protects is a convenience, not a backup.
• What happens to backups when I cancel or delete the server?
• Has anyone restored one recently?

That last one matters most. As the house line goes, a backup nobody has restored is a hypothesis. We have strong views on testing restores before you need them, and they are in testing a restore before you need it and backups that actually restore.

On RE:NODE, every plan has backup slots: on demand or scheduled, restored with a button, downloadable, lockable against rotation and stored off the machine they protect. Deleting a server deletes its backups, locked ones included - which is exactly the kind of detail you should look for on any host, because people learn it the wrong way. Separately, the platform takes nightly backups copied to separate hardware. Neither replaces a copy you keep yourself, and we would say that about any host's backups, RE:NODE's included.

Panel, file and console access#

The question here is how much of your own server you can reach without asking anyone. The less you can reach, the more every small problem becomes a support ticket, and the harder it is to leave.

For a game server or app host on a panel, the minimum we would accept:

• A live console with the raw, unfiltered output and a command line. If a host only shows you a cleaned-up log or a "server is running" badge, you cannot diagnose anything yourself.
• A file manager and SFTP. The file manager is for quick edits; SFTP is how you move a whole world, a modpack or a site in and out. No SFTP is a red flag on its own.
• The startup command or at least its variables. You will eventually need a launch flag, a JVM option or a different branch.
• Resource graphs against the limits, so you can see whether you are hitting the CPU share or the memory ceiling.
• Control over who else gets access, with permissions narrower than "everything".

For a VDS, the minimum is root, a way to reinstall, and some out-of-band console (VNC or serial) for when you lock yourself out with a firewall rule. Ask what you get if SSH stops answering. "Open a ticket" is a weak answer.

There is also an exit question hiding in here. Can you get all of your data out, in a normal format, without the host's help? If the answer is yes, a bad host costs you a weekend. If it is no, it costs you whatever they decide.

What the RE:NODE panel gives every plan, without tiers: an unfiltered live console with a command line, a file manager, SFTP with credentials per server rather than per account, a Startup tab for game and environment variables, CPU, memory and disk graphs against the limits, and subusers with granular permissions. It is built on Pterodactyl and Wings with our own panel on top, so if you know Pterodactyl, the shape will be familiar - what Pterodactyl is covers that.

Support you can reach#

The thing nobody can tell from a plan page is what support is like, and it is the thing that decides whether you stay. Hosting is a support business with servers attached.

What to look for:

• More than one channel, and at least one that leaves a written trail. A ticket system where your attachments stay private beats a public Discord channel for anything involving credentials or logs.
• A clear statement of when people are actually there. "24/7 support" from a small host often means "someone gets a notification". That is not dishonest, but it is not the same as a person on shift. We would rather a host told you its real hours.
• Answers written by someone who read the question. A pasted knowledge-base link in reply to a specific question is a sign of a team triaging by keyword.
• Whether support can do things, not just relay them. Can the person answering restore a backup, open a port, move a server? Or do they open an internal ticket and wait for an engineer?

Here is the uncomfortable thing from the operator side: small hosts are often better at support than large ones, because the person answering frequently wrote the code, and worse at coverage, because there are fewer of them. Big hosts tend to be the reverse. Decide which you need. A hobby server can wait until morning; a paid community or a business app may not.

RE:NODE support is a ticket from the panel (it reaches all staff, with private attachments), Discord and email. We do not advertise round-the-clock staffing, and we would not trust a host our size that did.

Testing a host in the first week#

You learn more in the first week on a host than from any amount of reading reviews. Treat the first payment as the cost of a test, and run the test deliberately. Where a host offers a short term, take it.

The route test matters first, because no amount of CPU fixes a bad path between the machine and your players. Run it from where your players actually are, not from where you are:

$ mtr -rwc 100 203.0.113.10$ fio --name=rand --rw=randread --bs=4k --size=1G --iodepth=32 \    --ioengine=libaio --direct=1 --runtime=30 --time_based

The address there is a documentation example - put in your server's. Reading traceroute and mtr explains how to read the output, and the most common misreading: loss on a middle hop that does not continue to the last hop is usually a router deprioritising the probes, not real loss.

Then load the server the way you will use it, at the hours you will use it. A machine that benchmarks well at 10am on a Tuesday and crawls on Saturday evening has a capacity problem that a single benchmark will not show. Repeat the one-thread sysbench run at a few different times and compare.

Ask support one real question you already know the answer to, and note how long the reply takes and whether it is right. Take a backup, delete a file you can live without, restore it, download the archive, and open it on your own machine. Pull your data out the way you would if you were leaving. If any of these is hard in week one, it will be worse in month six.

Red flags#

Some of these are dealbreakers; some are just a reason to ask harder questions. We have tried to only list things we would also hold our own platform to.

• No CPU model anywhere, and evasion when you ask.
• "Unlimited" everything, with no fair-use section you can find.
• A status page that has never shown an incident.
• A DDoS protection claim with a large number and no explanation of what is filtered. Real protection drops obvious volumetric floods; attacks that look like real players are much harder, and anyone promising to stop everything is selling you a sentence, not a service. There is more on that in DDoS attacks on game servers explained.
• No SFTP, no raw console, or backups you can only restore through a ticket.
• No way to export your data, or an export locked behind a cancellation.
• Lifetime plans, or prices so far below everyone else's that the arithmetic cannot work. Hardware, power and bandwidth cost the same for everyone in a given market; a plan priced below that is subsidised by something - overselling, a short life, or both.
• Terms that let the host suspend you for using the resources you paid for. Running at 100% of your CPU share should make your server slow, not get it removed.
• Pressure to buy a long term up front before you have tested anything.

None of these is proof a host is bad. Several together usually are.

The trade-offs we would make again#

A few opinions, stated plainly, from running one of these.

We would take a host that admits its limits over one that hides them. Every host has a ceiling on bandwidth, a support rota with gaps, a location that suits some players and not others. The ones that write those down are the ones you can plan around. RE:NODE runs in one location, Germany, on hardware we run - that is the right answer for players in Europe and the wrong one for players far away, and we would rather you knew that before you paid.

We would take fewer features and more access. A panel with an honest console, SFTP and real backups beats one with a hundred one-click buttons and no shell.

We would always keep our own copy of anything that matters, on someone else's infrastructure. Not because hosts are careless, but because the failure you are protecting against might be the host itself - a billing mistake, a closed account, a company that stops trading.

And we would test before committing. Every host, including ours, looks better on its own website than it does at 3am. The first week is where you find out which ones look the same.

If you want the wider view on what kind of server to rent in the first place, VPS vs VDS vs dedicated server is the place to start.

FAQ#

Is a higher core count always better for a game server?

No. Most game servers are limited by how fast one core is, because the main simulation loop runs on a single thread. A plan with fewer cores on a newer, higher-clocked CPU will usually run a busy game server better than more cores on an older or many-core chip. Extra cores help with mods, plugins, chunk generation and running several servers side by side.

What is the difference between unmetered and unlimited bandwidth?

Unmetered means you are not billed per gigabyte transferred. Unlimited is a marketing word for the same thing and should never be read as no ceiling at all - every host has a shared uplink and a fair-use point. The useful question is what the host does when you reach it: throttle, warn or suspend.

Should I trust a 99.9% uptime guarantee?

Treat it as a statement about compensation, not about reliability. It allows about 43 minutes of downtime in a 30-day month, the measurement interval decides what counts, and the remedy is usually a partial credit. A status page with real incident history tells you more about how a host operates than the percentage does.

Are the host's backups enough on their own?

They are a good first line and nothing more. Make sure you can restore and download them yourself, and keep at least one recent copy somewhere else entirely - your own machine or separate object storage. If the problem is the host account itself, backups stored with that host do not help.

How long should I test a new host before committing?

A week of normal use, including your busiest hours, is enough to find most problems: route quality, CPU contention at peak, support response, and whether restores and exports actually work. Avoid paying for a long term until that week is behind you, even if it is cheaper per month.

Is a small host riskier than a big one?

Differently risky. A small host is more likely to have support from people who built the system and less likely to have staff on shift at every hour. A big host has more coverage and more layers between you and an engineer. Your own backups and an easy way to export your data make either choice much safer.