The two most expensive VPS sizing mistakes pull in opposite directions: buy the cheapest plan and watch it fall over at peak traffic, or buy the biggest plan “to be safe” and pay for 7 GB of RAM you never touch. Both cost money every month. The table below is the short version of a repeatable sizing method — inventory, measure, reference, add headroom, check bandwidth, then match to a plan — that tells you how much VPS you need before you sign up.
| Workload | Steady RAM | Peak RAM | Comfortable plan |
|---|---|---|---|
| Static site + Nginx | 180–300 MB | 400 MB | 1 GB |
| WordPress + PHP-FPM + Redis | 700–900 MB | 1.2 GB | 2 GB |
| WordPress + MySQL, no cache | 1.1–1.4 GB | 1.8 GB | 2–3 GB |
| Node.js app + Postgres | 900 MB–1.3 GB | 1.7 GB | 2–4 GB |
| Docker Compose, 3 containers | 1.4–1.9 GB | 2.4 GB | 4 GB |
Those numbers are only useful if you size to the peak column, not the steady column. A plan matched to steady-state usage will swap every evening at traffic peak. If you are still comparing provider tiers, our budget VPS plan breakdown maps these RAM brackets to real monthly prices so you can see the cost of each step up.
Step 1: Inventory Every Service
List everything the server will run, with rough concurrency: web server, database, cache, queue workers, cron jobs, backup scripts, monitoring agents. A WordPress site with Redis and one cron job needs different resources than the same site with two background workers and a local monitoring stack. Write the list down — sizing is only as good as the inventory. Then add the operating system baseline: a bare Linux install with SSH, systemd, and journald idles at roughly 120–200 MB, which matters on a 512 MB plan.
Step 2: Measure Instead of Guessing
If you already run a server (shared hosting or another VPS), measure it for seven days before deciding anything. Free tools are enough: htop for CPU, free -m for RAM, iostat for disk, vnstat for bandwidth, or a lightweight agent like Netdata for graphs. Record peak values, not averages. A plan sized to the average will swap at 9 PM every night, and swap on NVMe still costs latency.
free -m | awk 'NR==2{printf "used: %s MB of %s MB\n", $3, $2}'
vmstat 5 12 | awk 'NR>2{print "si/so:", $7"/"$8}'
sar -u -f /var/log/sysstat/sa$(date +%d) | tail -5Any non-zero si or so in vmstat means the server is already swapping. That is your signal to size up, not a signal to tune harder.
Step 3: Derive CPU From Concurrency, Not Traffic
Traffic totals are useless for CPU sizing; concurrent requests are what matter. A typical dynamic PHP request consumes 40–80 ms of CPU. To serve 20 concurrent requests inside 300 ms of latency, you need roughly 5–6 worker processes’ worth of CPU — which a 2 vCPU plan handles if the vCPUs are dedicated rather than heavily shared.
- 1 vCPU: static sites, single-worker apps, low-traffic APIs
- 2 vCPU: WordPress, small Node.js/Python apps, most side projects
- 4 vCPU: WooCommerce, multi-site, build servers, anything with a queue
- 6+ vCPU: databases under load, video encoding, ML inference
Step 4: Add Structured Headroom
Use 60–70% as your steady-state target and leave the rest free. That gives you room for traffic spikes, backups, and kernel page cache. Concretely: if steady usage measures 1.2 GB, buy 2 GB, not 1.5 GB. Headroom is cheaper than an emergency migration at 2 AM, and it protects you from noisy-neighbor CPU steal you cannot control.
Step 5: Check Disk and Bandwidth Separately
Storage adds up faster than expected: OS and packages (5–8 GB), database growth, logs, backups, and, if you use Docker, the image layer cache. Budget 2× your current data footprint. Bandwidth deserves its own calculation — sum monthly page views × average page weight, then multiply by 2 for overhead. A 100,000-view site with 800 KB average pages moves about 160 GB/month before images and API traffic.
Step 6: Match to a Plan and Verify
Only now compare prices. Set the RAM bracket first, then CPU, then storage, then bandwidth, and pick the cheapest plan that satisfies all four. If two providers tie on paper, buy the one with a money-back window and run a benchmark during it. Our comparison of budget VPS providers with real specs lists trial periods and renewal pricing so the tie-break is data-based rather than marketing-based.
Two last checks before you commit:
- Confirm the virtualization type. KVM gives predictable resources; container-based plans often share memory and CPU more aggressively.
- Confirm renewal pricing, not just first-term pricing. A $3 intro rate that renews at $9 changes the three-year math completely.
If you want a plan that already sits in the right bracket with transparent renewal pricing, InterServer’s VPS line locks your rate permanently, which removes the renewal-increase risk from this calculation: InterServer VPS plans. For short-lived projects where you can resize up and down by the hour, Vultr’s hourly billing lets you test a sizing guess cheaply before committing to a year.
Sizing is not a one-time decision. Re-run steps 2 and 4 quarterly; workloads drift, and a plan that was correct last spring is often the wrong shape by autumn.
