Choosing VPS specs feels like a guessing game because most guides answer the wrong question. They tell you what a 4 GB plan costs, not whether your site needs 4 GB. Almost everyone starts oversized and pays for idle resources for months. This guide flips that around: start from your workload, size each resource on real numbers, and learn the two commands that tell you exactly when to upgrade.
The 60-second answer: recommended VPS specs per use case
Typical starting specs for common workloads. Start at the small end and scale up when real usage says so.
| Use case | vCPU | RAM | Storage | What matters most |
|---|---|---|---|---|
| Static site / landing page | 1 | 1 GB | 20 GB NVMe | Uptime, not power |
| Small WordPress blog (under ~50k visits/month) | 1-2 | 2 GB | 40 GB NVMe | RAM and a cache plugin |
| Busy WordPress / WooCommerce | 2-4 | 4-8 GB | 80 GB NVMe | RAM for PHP workers, fast disk for the database |
| Node.js / Python API backend | 2 | 4 GB | 40-60 GB NVMe | Single-core speed and memory headroom |
| MySQL / PostgreSQL database server | 2-4 | 8 GB+ | 100 GB+ NVMe | RAM for buffer pools, IOPS for reads/writes |
| Dev / staging playground | 1 | 2 GB | 30 GB NVMe | Cheap and disposable |
Prices vary between providers and regions, so check official pricing pages. The sizing logic stays the same.
Start from the workload, not the plan page
A VPS plan page lists four numbers: vCPU, RAM, storage, and bandwidth. Before touching any of them, write down what the server will actually run: an operating system, a web server (Nginx or Apache), PHP-FPM or an app runtime, a database, and maybe Redis. Each has a roughly known memory footprint, and adding them up gets you within 30% of your real need. That beats picking a plan by feel every time.
A rough memory budget: the OS takes 300-500 MB, Nginx barely registers, each PHP-FPM worker takes 30-60 MB, and MySQL eats 500 MB to 2 GB depending on how much data you let it cache. Add it up and you can see why a small WordPress site lives on 2 GB while a database-heavy app wants 8.
RAM: the spec that matters most
On a VPS, running out of RAM hurts more than running out of anything else. When RAM fills up, Linux starts swapping to disk, which is hundreds of times slower than memory, so response times fall off a cliff. CPU saturation slows things gradually. RAM exhaustion makes everything crawl at once.
That is why the practical sizing rule is simple: pick enough RAM that normal load uses about 60-70% of it. The leftover headroom covers traffic spikes and the filesystem cache, which Linux uses to keep frequently read files in memory. A server sitting at 90%+ memory use on an ordinary day is undersized. One sitting at 20% on its busiest day is money you could be spending elsewhere.
For WordPress, the two biggest RAM levers are the number of PHP-FPM workers and object caching. Halving an idle worker pool or adding Redis often frees more RAM than a plan upgrade would add. Tune first, then buy.
CPU: what a vCPU actually is
A vCPU is not a physical core. It is a time slice of a physical core on the host machine, shared with other tenants. On budget plans, that sharing is the whole game: if a neighbor runs a compile job at the wrong moment, your slice shrinks. This is the “noisy neighbor” problem, and it is the main reason two identically specced VPS plans from different providers can feel so different.
Two things are worth checking before you buy. First, whether the vCPUs are shared or dedicated. Dedicated plans cost more but guarantee your slice, which matters for sustained loads like video encoding or busy databases. For a typical website that idles most of the time, shared vCPUs are fine. Second, clock speed matters more than core count for single-threaded work. A PHP request or Node.js handler runs on one core at a time, so 2 fast cores beat 4 slow ones for most web workloads.
Once the server is running, htop shows a metric most people ignore: steal time (the st column in top). Steal time is the percentage of CPU cycles the hypervisor took back for other tenants. A few percent occasionally is normal on shared plans. Sustained double-digit steal means the host node is oversold, and no spec upgrade on that node will fix it. That is a provider problem, not a sizing problem.
Storage: NVMe vs SSD, and how much you really need
Storage has two dimensions: how much space, and how fast it is. Space is the easy one. A typical WordPress install with theme, plugins, and a few hundred megabytes of uploads fits in under 2 GB; the OS and logs take another 5-10 GB. What eats disk over time is backups, media uploads, and database growth. Keep at least 30% free at all times, because full disks cause the ugliest failures: databases refuse writes and updates fail halfway.
Speed is where the acronyms come in. A SATA SSD is already fine for most websites. NVMe is often several times quicker on random reads and writes, which is exactly the pattern databases and PHP opcode caches produce. For a database server or a WooCommerce store, NVMe is worth having. For a static site, you would never notice the difference. Avoid spinning HDD storage for anything user-facing; it belongs on backup and archive tiers only.
Bandwidth: port speed vs transfer allowance
Providers advertise bandwidth two ways. Port speed (100 Mbps, 1 Gbps) is how fast data can move at any instant. The transfer allowance (1 TB/month, 5 TB/month) is how much total data you can push before overage fees or throttling.
For most websites, the allowance matters more. A 2 MB page served 50,000 times a month moves about 100 GB, which fits inside even modest 1-2 TB allowances. Port speed only becomes the bottleneck for large downloads, video streaming, or spikes that saturate the link. If you run a media-heavy site, put a CDN like Cloudflare in front of the VPS rather than buying a bigger pipe.
Already have a server? Read its real usage first
If you are resizing an existing VPS, stop guessing. Two commands tell you everything:
htop
free -h
df -hIn htop, watch three things. The load average: on a 2-vCPU box, a sustained load above 2.0 means the CPUs cannot keep up. The memory bar: if the swap row shows more than a few megabytes in regular use, you need more RAM. The per-core bars: all cores near 100% during normal traffic means you need more CPU; brief spikes that settle mean you are fine.
Run these during your busiest hour, not at 3 AM. Sizing from idle numbers is how servers end up falling over every Monday morning.
The upgrade rule: start small, monitor, scale
The cheapest sizing strategy is also the most reliable: buy the smallest spec that fits the table above, run it for two to four weeks, then check htop during peak hours. Upgrade only the resource that is actually constrained: RAM-bound means add RAM, pegged CPUs with memory half empty means add vCPU, disk at 80% means grow the volume or clean up.
Most providers let you resize a VPS in minutes, many without reinstalling anything. That upgrade path is why oversizing on day one is wasted money. The savings from right-sizing in the first six months usually cover several upgrades later, and you only pay for the bigger box once you actually need it.
Mistakes that waste money
- Buying 8 GB “to be safe” for a brochure site. Idle RAM earns nothing. Start at 1-2 GB and watch the graphs.
- Ignoring disk speed on database workloads. A slow disk makes a fast CPU wait. For MySQL or PostgreSQL, NVMe matters more than an extra vCPU.
- Confusing vCPU count with performance. Four shared, oversold cores can lose to two fast dedicated ones. Check steal time before blaming your code.
- Forgetting backups in the disk budget. A 40 GB disk with 35 GB used and no room for a database dump is a 3 AM emergency waiting to happen.
- Sizing from averages instead of peaks. The server has to survive the busiest hour, not the average one.
Quick checklist before you buy
- Write down the workload: OS, web server, app runtime, database, cache.
- Size RAM first: enough for 60-70% use at normal load.
- Pick shared vCPUs for typical websites, dedicated for sustained heavy loads.
- Choose NVMe storage with at least 30% free space planned in.
- Check the transfer allowance against your expected monthly traffic.
- Confirm the provider allows easy resizing later.
- After launch, verify with
htopduring peak hours and adjust.
Right-sizing is not a one-time decision. Check real usage every few months, upgrade one resource at a time, and you will spend less than everyone who bought big “just in case” and never looked back.