How to size a VPS without overpaying

VPS plans are sold as tidy rows of numbers, but workloads don’t read the plan table. The good news: sizing doesn’t need to be a prediction exercise. Start from what you can measure or reasonably estimate, leave honest headroom, and treat the first size as a hypothesis — resizing a VPS is routine on most platforms, so a wrong guess costs you a short maintenance window, not a migration.

Start from the workload, not the plan table

List what will actually run: web server, application runtime, database, cache, background workers, scheduled jobs, monitoring agent, backup process. Each is a permanent tenant with its own memory and CPU appetite. A “small” site running a database, a PHP-FPM pool, and a Redis cache on one server is three tenants, not one.

If the workload already runs somewhere — shared hosting, an old server, a laptop — measure it there first. Real usage numbers, even from imperfect environments, beat any rule of thumb below.

Memory: the usual first limit

Memory is where most undersized servers fail first, because running out is abrupt: the kernel starts killing processes, and the process it kills is usually the database. Add up the resident memory of every service, then the per-request memory of your application multiplied by how many requests you’ll serve concurrently, then leave room for the filesystem cache — Linux uses spare memory to cache disk reads, and databases in particular get much of their speed from it.

A minimal single-site setup can live in a small allocation; a database plus an application pool plus a cache grows from there quickly. Watch two signals once running:

free -h
vmstat 5 5

Sustained swap activity in vmstat (the si/so columns) means the server is already too small for how it’s configured — either add memory or shrink the tenants.

CPU: bursts are fine, saturation is not

Web workloads are bursty; short spikes to 100% during a deploy or a traffic surge are normal and harmless. What matters is sustained saturation: a load average persistently above the number of cores means requests are queueing.

On virtualized servers, also watch steal time (st in vmstat or top) — it’s time the physical host gave to other tenants instead of your VPS. Consistently elevated steal means the contention is on the host’s side, and no amount of tuning inside your server fixes it; that’s a conversation with the provider or a move to a plan with dedicated cores.

Disk: size for growth, speed for databases

Space needs are simple arithmetic — OS and packages, application, uploads, databases, logs, and local backup staging — but growth is the real variable. Logs and uploads expand quietly; a database needs free space for its own maintenance operations. Filling a disk to 100% takes most services down harder than a reboot, so alarm well before that.

For anything database-heavy, storage latency matters more than storage size. A modest database on fast NVMe storage will outrun a large one on slow disks. Check both dimensions:

df -h
df -i

Inodes (df -i) run out separately from space — a surprise reserved for servers hosting many small files.

Transfer: usually fine, occasionally decisive

Estimate monthly transfer as average page weight × monthly page views, plus backups shipped off-server, plus any media traffic. Most conventional sites sit comfortably inside typical plan allowances. The exceptions are predictable: video, large downloads, popular APIs, and image-heavy catalogs. If that’s you, check the overage terms before choosing a plan — and consider whether a CDN should carry those bytes instead of the VPS.

Leave headroom, then let measurements drive resizes

Size so that normal operation uses roughly half to two-thirds of memory and CPU. That headroom isn’t waste — it’s what absorbs traffic spikes, background jobs, and updates without drama, and it’s what keeps performance predictable while you sleep.

Then stop guessing and start measuring. The monitoring guide covers the baseline; the sizing rule that falls out of it is simple: resize when a resource shows sustained pressure, not on the first spike. Growth you can see in a graph is a purchase justification; growth you can only imagine is not.

One caution before reaching for a bigger plan: a slow site on a lightly loaded server is not a sizing problem. A missing cache or one bad database query can make any server feel small, and renting more hardware to hide it just makes the problem more expensive. The site speed guide covers finding the actual bottleneck first.

Decision checklist

1. What are the permanent tenants, and what do they need at rest?
2. What does one concurrent request cost, and how many will peak hours bring?
3. How fast do disk, logs, and database grow per month?
4. Does the workload have evidence-backed transfer or storage-speed demands?
5. Is there headroom left after all of the above — and monitoring in place to tell you when it shrinks?

If you’re still deciding whether a VPS is the right model at all, start with shared hosting vs VPS; if the server is chosen and waiting, getting started with a Linux VPS covers the first hour.