How to choose a VPS for your server

Before you look at plans, size up what goes on top

The usual mistake is to start with the pricing table and pick by budget. The more useful question comes first: what is this machine going to do, and how many people will hit it at once? A brochure site that gets the odd visitor through the day is a completely different animal from a service that accepts file uploads or queries a database on every click.

A rough estimate is plenty. Count the concurrent users at your busiest hour — not the monthly total — whether the work is mostly reading or mostly writing, and whether certain moments bunch the load together: a big mail send, an end-of-month close, the day of a promotion. And if something is already running, look at the real usage over the last few weeks before assuming anything; it almost always surprises you, one way or the other. With those four answers on the table, the choice stops being a gamble.

Memory: almost always the first thing to run out

Memory is usually the first thing to run dry. Set aside 1–2 GB for the operating system and its background chores, then hand the rest to your service. While there is headroom everything feels quick; the moment it runs out, the system starts leaning on swap — pretend memory backed by the disk, which is orders of magnitude slower — and the whole box crawls even while the CPU sits idle. That is the classic tell of an under-sized server: it does not run hot, it seizes up.

A database makes it obvious. If the working set fits in memory, queries fly because nothing touches the disk; once it stops fitting, every query starts reading from disk and you feel the drop straight away. So give whatever you cache in memory plenty of room. Overshooting is not free either — paying for 32 GB to use 6 is money walking out the door every month for nothing.

CPU: count the cores, but mostly how they get used

Two separate things matter with CPU: how many cores you get, and how fast each one is. Lots of short, light requests spread nicely across several cores, so there extra cores genuinely help. A single heavy, sequential job, though — building a big report, compressing a dump, a calculation you cannot split up — rides on how fast one core is, and piling on more will not speed it up in the slightest.

There is fine print around the term "vCPU": on many plans these are cores shared with other tenants on the same physical host. When a neighbour gets greedy, your service feels the tug — that is steal time, CPU cycles that were yours going to someone else. For anything sensitive to lag, check whether the provider offers dedicated or guaranteed cores rather than settling for the headline number.

Disk: type, speed, and what creeps up on you

Almost nobody checks the disk type, and it changes the experience more than almost anything. A solid-state disk (SSD, and better still NVMe) runs rings around a mechanical one when there are lots of small reads and writes — exactly what a database does all day long. And it is not only transfer speed: it is operations per second (IOPS), which is where a slow disk chokes a service without the CPU graph showing anything odd.

Size the disk for where you are heading, not where you are today. Add the growth of your data, the logs that pile up day after day, and above all the backups if you keep any on the machine itself. A classic trip-up: unrotated logs fill the disk to 100% and take the service down — not for want of power, but because there is no free byte left to write to. Always leave a generous margin; a completely full disk is one of the silliest and most avoidable failures there is.

Turning all of that into a starting point

With a rough idea of the load and those three pieces in mind, you can land on an actual size. The table below gives ballpark figures by type of project: enough to avoid overpaying or starting out short, not a fixed menu. A real project might want more than one row at once, or sit somewhere between two; take it as a nudge, not a rule.

The "headroom" column is the one people forget. Leaving room for a local backup, sizing for the peak instead of the average, or being able to move up a plan without reinstalling everything: that is what separates a server that copes from one that runs on fumes from day one.

Network: bandwidth, IP, and being near your visitors

Network comes down to a handful of things worth checking before you sign up, not after:

• Included transfer. Some plans meter monthly traffic and either bill you extra or throttle the speed once you go over. If the service moves files or video, read that limit closely.
• IP and ports. Confirm you can open the ports you need and, if the service calls for it, that the IP is your own rather than shared with strangers.
• Attack protection. A baseline of DDoS mitigation out of the box stops a dumb flood from knocking you offline for a while.
• Distance. The further the data centre sits from your visitors, the longer every request takes to go and come back. For a local audience, picking a nearby region shaves latency without costing a cent more.

The OS, your access, and the provider's fine print

Real control needs administrator (root) access on a stable, long-supported distribution. With it you set up the firewall, background services, scheduled jobs (cron) and security hardening; without it, half the setup is out of reach and you depend on the provider for anything at all.

Two mix-ups that cost money. First: a snapshot is not a backup. It lives on the same infrastructure and saves you from a clumsy change, not from the provider having a bad day. Second is scaling: check before you sign up whether you can move up a plan without reinstalling and with only a short outage, because the day you need more muscle you will not want to start from scratch.

Be wary of the fine print. "Up to X GB", resources listed as "shared" where you expected guaranteed, or support that takes days to reply — none of it shows in the pricing table, and all of it comes due exactly when something breaks.