How to choose a VPS: a task-first walkthrough

"Get some headroom" is not a method; it is a way to overpay for idle capacity. This is how to choose a VPS for a specific project instead: list what will run on the box, size the CPU, RAM and disk against that load, decode the marketing phrasing behind "200 Mbps port" and "unlimited", and benchmark the machine in the first hour after payment. A VPS here is a rented virtual machine with full (root) access that behaves like a standalone server while sharing physical hardware with other tenants. Commands target Ubuntu 22.04, 24.04 and 26.04; Debian is the same except where noted.

TL;DR. Size from the workload, not from the plan table. Static sites and landing pages run on 1 GB RAM and 1 core; WordPress and a small shop need 2-4 GB and 2 cores; several Docker services or a busy database start at 8 GB and 4 cores. Disk: SSD, with NVMe worth it for heavy random I/O and HDD only for archives. Virtualization: KVM, for its own kernel and compatibility with a normal Linux stack; whether CPU, RAM and disk are truly reserved, and whether you can resize without a reinstall, is set by the plan and the provider, not by KVM itself, so verify it with a benchmark. A "200 Mbps port" is link width (roughly 90 GB per hour at the ceiling); "unlimited" means the volume is not billed, but speed is still capped by the port. After you rent the box, run fio, sysbench and iperf3 5-10 times each and read the range, not a single number.

How to choose a VPS: start with what will run on the server

The real first step in how to choose a VPS is an inventory of load, not a price list: write down everything that runs at the same time. A typical CMS site is not one process but a stack: a web server, an interpreter (PHP-FPM, Node.js, Python), a database, often a cache (Redis), plus scheduled jobs. Each of these holds memory even when nobody is visiting. Your configuration has to cover the sum of those appetites at peak traffic, not the 24-hour average.

Then a fork. One project per server: sizing is simple and upgrades are predictable. Everything on one box (several sites, a bot, a database, monitoring): cheaper up front, but the loads stack and interfere, and one heavy database query on site A drags down response times for the rest. For anything that clients or revenue depend on, keep it separate. Stacking everything into one box is fine for side projects and a staging environment.

If the labels "VPS", "VDS", "cloud" and "dedicated" blur together, that has its own breakdown. Here one thing matters: the virtualization type and the resource guarantees, not the letters in the plan name.

Treat this as a starting point, not a guarantee. Real numbers depend on the WordPress theme, the plugin count, the catalogue size and the traffic: a heavy Elementor build can eat twice the memory of a stock theme. The only number that fits your load is a measured one, and the section below shows how to get it.

You can build any of these rows on the VPS plans page: the ladder is the same in every location (from 1 vCPU / 1 GB / 20 GB SSD up to 16 / 64 / 500), only the point of presence and the price differ. Below is the same table with a link to the matching plan; prices follow the Sweden line as a reference. Pick the location by where your audience is: the newer EU sites - Sweden, Finland, France - run a 200 Mbps port.

How many CPU cores your project needs

A vCPU is a virtual core the hypervisor assigns to your machine from the host's physical processor. One or two vCPUs are enough for most CMS sites: under ordinary traffic the CPU is busy in short bursts, and the bottleneck is more often the database, disk latency or heavy plugins than the core count. PHP does execute on the CPU, though, so a site with slow plugins and no caching can be CPU-bound too - trust the measurement, not the general rule.

More cores pay off when the server does continuous background work: a task queue that is always chewing on something, video or image transcoding, front-end builds, scraping, backup compression. Those loads keep the CPU busy without pause, and every extra core genuinely shortens the job.

Load average tells you whether there is room. It is the average number of processes that are either running on a CPU, waiting for one, or stuck waiting on disk (state D). The three figures are 1-, 5- and 15-minute windows. Check it against the core count:

nproc
uptime

• nproc prints the number of available vCPUs.
• uptime ends with those three load average figures.

Heuristic: if the average load (the second or third figure) stays below the core count, the CPU has room to grow. It is a heuristic, not a rule. Load average also counts processes in state D (disk wait), so a high load on its own does not mean "CPU-bound". Cross-check with the time breakdown in top:

top

• The %Cpu(s) row: us is your code, sy is the kernel, wa is I/O wait, st is time the hypervisor gave to other tenants.
• High load but low us+sy with a large wa means you are disk-bound, and adding cores will not help.
• a steadily high st that lines up in time with response dips means the VM is regularly missing CPU time at the hypervisor level. A common cause is contention or an oversubscribed host, but st alone will not tell you which; 10% here is an example of a noticeable value, not a diagnostic threshold.
• Press 1 to see per-core usage.

How much RAM to get, and how to size it

A memory shortfall takes the service down at once, so size it from what you measure. Measure peak working usage under real load and leave a margin for spikes; as a starting estimate people add 30-40%, but there is no single percentage that fits every project. There is no such thing as "idle" memory here: Linux hands any free RAM to the filesystem cache (recently read files), which is why you read available, not free.

Current state:

free -h

• The available column is what you can actually claim without touching swap. Read that, not free.
• Used swap on its own is not a shortage: the kernel can leave long-evicted cold pages there even after RAM has freed up. The warning sign is the combination - a low available together with active paging (below).

Check whether the kernel has been killing processes over memory. The OOM killer is the Linux kernel mechanism that picks and terminates a process when memory runs out; it can also fire on a container limit while the host still has free memory.

sudo journalctl -k | grep -iE 'out of memory|killed process'

• Lines here mean memory ran short and something died. Empty output means this front is quiet for now.
• If the journal keeps no history, the same information is in sudo dmesg -T | grep -i oom.

And see whether paging is happening right now:

vmstat 1 5

• The si and so columns are swap-in and swap-out rates in KB/s. Sustained non-zero values together with a low available and a drop in performance are real memory pressure - add RAM. A one-off burst while services start is normal.
• swpd is how much swap is already in use. The first vmstat report is an average since boot; read from the second line on.

On "is 1 GB enough": for a static site, yes, with plenty to spare. For WordPress on 1 GB you will be riding the edge of swap on the first traffic bump or heavy plugin; take 2 GB and stop worrying about it.

Which disk to choose: NVMe, SSD or HDD

Two numbers describe a disk from the server's point of view. IOPS is input/output operations per second. Latency is how long one operation takes. For a database and for serving many small files, both matter: this is thousands of scattered small reads and writes, not one large sequential stream.

An SSD of any kind is several times faster than an HDD on exactly that random load, because a mechanical drive has to move a head to the right track. The gap between NVMe and SATA SSD is narrower: benchmarks put NVMe at several times the IOPS and lower latency, but that shows mainly under heavy random load (a busy database, very many small files). On static delivery you are unlikely to notice it. HDDs today are for cold data only: archives, backups, a media library.

On capacity: the OS plus a typical site is 5-15 GB; after that the database, uploads and logs grow. Keep backups off the same disk, since it can die together with them.

When a site suddenly slows down, the cause is often the disk rather than the code: under load everything queues on it. A related topic is the breakdown of common web-server errors, where 502 and 504 also often turn out to be a resource shortage. How to measure the disk is in the benchmark section below.

KVM or OpenVZ: virtual machine versus container

These are two ways to slice a physical server into virtual machines, and the difference is practical.

KVM is a full virtual machine: the hypervisor emulates hardware, you get your own Linux kernel and full compatibility with a normal Linux stack. You can change kernel parameters (sysctl), bring up your own swap, install any distribution or a custom kernel, and run Docker and WireGuard without surprises. KVM on its own does not guarantee reserved CPU, RAM or IOPS, though: it supports CPU and memory overcommit and memory ballooning, so how honestly resources are allocated is a matter of the provider's configuration and policy, not the virtualization type.

OpenVZ, as a classic container VPS, is container virtualization: every container on the host shares one kernel. (The OpenVZ project itself now also ships KVM-based VMs, but on a plan "OpenVZ" usually means the container.) Memory is often configured as a guaranteed minimum plus burst above it while the host has spare - the specifics depend on the provider. Some kernel parameters are off-limits, and you do not pick the kernel version.

For predictability and compatibility, take KVM. OpenVZ is only worth it for a clear price cut on genuinely simple tasks. "VPS" and "VDS", meanwhile, are the same thing in practice - a rented virtual machine with root; "VDS" in ads sometimes hints at hardware virtualization, but nobody standardized the term.

What "200 Mbps port" and "unlimited" mean

A "200 Mbps port" is link width, the speed ceiling at any given moment, not a monthly cap. 200 megabits per second is 25 megabytes per second. At the ceiling that moves roughly 90 GB in an hour and, across a month of round-the-clock saturation, on the order of 65 TB. The figures are rounded (exact arithmetic depends on whether you count in gigabytes or gibibytes), but that is the order of magnitude.

"Unlimited" (also sold as "unmetered") means the volume of transferred data is not billed - you will not get an invoice for extra terabytes. Speed is still capped by the port, and many providers apply a fair-use policy under sustained saturation: they will ask you to move to a plan with committed bandwidth, or quietly shape the speed. Short spikes under load are not what that policy is about.

For an ordinary site, a 100-200 Mbps link will never be the bottleneck: the page takes longer to render than to transmit. Link width matters for large-file delivery, streaming and pushing backups off-site. How to check the real speed is the next section.

How to benchmark the server after you rent it

The provider promised cores, memory, a fast disk and a link. Verify that in the first hour, while the server is empty and easy to swap or return. The tools install with one command, and a minimal cloud image does not ship them:

sudo apt update
sudo apt install -y fio sysbench iperf3

• The packages come from the standard repository (on Ubuntu that is universe, usually already enabled; on Debian, main).

sysbench cpu --cpu-max-prime=20000 --threads=1 run

events per second

sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Disk. Random read/write in 4K blocks is the database access profile: many small scattered operations. The command creates a 1 GB test file and does real writes, so you need free space; delete the file afterwards.

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 \
--bs=4k --size=1G --numjobs=1 --iodepth=32 --runtime=60 --time_based \
--group_reporting

• --direct=1 bypasses the page cache, so you measure the disk and not memory.
• --rwmixread=70 is 70% reads, 30% writes, close to a typical database under load.
• --iodepth=32 is the queue depth: that many operations in flight at once (this works with the async libaio engine).
• --runtime=60 --time_based runs for exactly a minute regardless of file size.
• libaio is normally pulled in as a dependency of fio. The synchronous fallback is --ioengine=psync, but only with --iodepth=1: its numbers are a different test and cannot be compared directly with libaio at --iodepth=32.

What you will see: lines read: IOPS=... and write: IOPS=..., the mean completion latency (clat avg) and a clat percentiles block, especially the 99.00th row. Remove the test file: rm -f randrw.0.0.

CPU. sysbench computes primes up to 20000 - a clean CPU load with no disk or network.

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

• Read the events per second line.
• The second run uses every core; $(nproc) fills in the count. The result should rise noticeably over the single thread, but not by an exact multiple of the vCPU count: SMT, turbo boost, thermal and power limits and the scheduler all get in the way. If the multi-threaded result is unstable between runs or drops at the same time as a high st, that is a reason to suspect contention on the host.

Network. You need a reachable iperf3 server: the provider's, one in the same data centre, or a public one. Public servers are often congested and will cap the speed - that is not a measure of your port. Test against a nearby node: a distant one limits throughput by link latency, not by your port.

iperf3 -c SPEEDTEST_HOST -p 5201 -t 20
iperf3 -c SPEEDTEST_HOST -p 5201 -t 20 -R

• -t 20 is a twenty-second test. -R reverses direction, giving a download to you.
• The final sender and receiver lines are the average speed for the test. Compare that with the promised 200 Mbps (or whatever the plan states).

Real response. iperf3 and fio measure hardware in isolation; a visitor sees the sum of network time plus page rendering.

for i in $(seq 1 10); do
curl -o /dev/null -s -w '%{time_total}\n' https://your-site/
done

• Each curl run is a fresh request; the connection is not reused, which is why you run it ten times.
• Look at the spread. Steady values are good; swings of several times mean the server or the link is under load.

General rule: run each test 5-10 times and read the range, not a single number. I am deliberately not quoting "normal" figures, because they depend heavily on the host's hardware generation and on your neighbours. Your one reference is what the plan promised, plus a repeat measurement on another day.

When a VPS is no longer enough

Decide to move on measurements, not on a feeling that it "lags". Signs that you are genuinely capped:

• load average steadily above the core count, with top showing us+sy near 100% rather than wa - the CPU really is short;
• available in free -h stays low, and vmstat shows sustained si/so;
• fio hits an IOPS ceiling that matches the plan's limit;
• the st column in top stays high and lines up in time with performance dips (a common cause is contention or an oversubscribed host).

Order of moves. First, upgrade: CPU, memory and disk usually grow without reinstalling the system, with a short reboot, where the provider supports it. Next, split services: the database on its own server, the application on another. A managed database takes its administration off your plate. A dedicated server is for when you need the whole physical machine predictably and without neighbours: constant high load, licensing requirements, a heavy 24/7 database. For everything else a VPS is cheaper and more flexible.

FAQ

How much RAM does a VPS need?

Static sites run on 1 GB, WordPress or a small shop on 2-4 GB, a busy database or several Docker services on 8 GB or more. Size it by peak working usage with a margin for spikes (as a starting estimate, plus 30-40% - not a fixed formula); read available rather than free, since Linux uses spare RAM for the filesystem cache. A shortfall shows up as a low available with constant paging (si/so in vmstat) and as the OOM killer firing (the kernel mechanism that terminates a process when memory runs out).

How many CPU cores for a website?

One or two cores are enough for most CMS sites: the bottleneck is usually the disk and the database, not the processor. You need more cores for continuous background work - queues, transcoding, builds, scraping. Rough guide: if the average load stays below the core count there is room; cross-check with the %Cpu row in top (us, sy, wa).

VPS or VDS - which one?

In practice they are the same: a rented virtual machine with full access. "VDS" in ads sometimes stresses hardware virtualization, but nobody standardized the term. Look at the virtualization type, the guarantees and the disk, not the letters. There is a fuller breakdown of VPS, VDS, cloud and dedicated.

KVM or OpenVZ?

KVM is a full virtual machine: its own kernel and compatibility with a normal Linux stack, freedom to change system parameters and install any distribution. Whether CPU and RAM are truly reserved, and whether you can resize without a reinstall, depends on the provider, not on the fact that it is KVM. OpenVZ is a container - the kernel is shared with neighbours and memory is often "floating". For predictability and compatibility, take KVM. OpenVZ is only justified by a clear price cut on genuinely simple tasks.

NVMe, SSD or HDD for a server?

An SSD of any kind is several times faster than an HDD on random load - which is exactly how a database and small-file serving behave. The gap between NVMe and SATA SSD shows mainly under heavy random load: benchmarks put NVMe at several times the operations per second. HDDs today are for cold archives and backups only. For a working server, aim for SSD, and NVMe where it is offered and the load calls for it.

How do I benchmark a VPS after renting it?

Disk with fio doing random read/write in 4K blocks, CPU with sysbench cpu, network with iperf3 to a nearby node plus a few curl runs against a real site. The packages install in one command: sudo apt install -y fio sysbench iperf3. Run each test 5-10 times and read the range, not a single number.

What do "200 Mbps port" and "unlimited bandwidth" mean?

200 Mbps is link width, the peak speed at a given moment; at the ceiling that moves roughly 90 GB in an hour (a rounded figure). "Unlimited" means the volume of transferred data is not billed, but speed is still capped by the port, and under round-the-clock saturation many providers apply a fair-use policy. For an ordinary site that link has plenty to spare.

Can I upgrade the plan later?

CPU, memory and disk usually upgrade without reinstalling the system - with a short reboot, where the provider supports it (most KVM hosts do). So you take the smallest sufficient configuration at the start and grow it as load demands. Disk usually grows only upward; you cannot shrink it. On WeaselCloud the plan change is done from the panel; the lines are on the VPS plans page.

In short

• Start from an inventory of load, not the plan table: first what runs on the server, then what it costs in resources.
• CPU: 1-2 cores for almost any CMS site; more only for continuous background work.
• RAM: size by peak working usage with a margin for spikes (starting estimate +30-40%); watch available. Constant paging (si/so) with a low available and the OOM killer are the signal to add memory.
• Disk: SSD for working load, NVMe for heavy random I/O, HDD only for archives and backups.
• Virtualization: KVM - its own kernel and Linux-stack compatibility; reserved resources and resize-without-reinstall depend on the provider, not on KVM.
• "200 Mbps port" is a speed ceiling (around 90 GB per hour); "unlimited" is about volume not being billed, not about speed.
• After payment, run fio, sysbench and iperf3 5-10 times each; compare with what the plan promised, not with a feeling.
• Grow on measurements: on KVM the plan scales up without a reinstall.

Once you have sized the configuration against your load, build it on the VPS plans page. KVM virtualization, SSD disks, a choice of location from Sweden and Finland to Moscow, and CPU, memory and disk upgrades afterwards from the panel without reinstalling the system. Start with the smallest sufficient spec and grow on measurements, not on "get the bigger one".