Choosing a VPS Plan: How Much vCPU, RAM & Disk You Need

Every VPS provider shows you a pricing table with numbers — 2 vCPU, 4GB RAM, 80GB disk — and expects you to just know which row fits your site. Most people either overspend "to be safe" or underspend and end up firefighting a slow server six months later. Here's how to actually size a plan instead of guessing.

Start with what's actually going to run on the box

Specs mean nothing without a workload attached to them. Before you look at a single price, answer this: what is this server doing all day?

• A single WordPress brochure site with low traffic
• A WooCommerce store processing orders and payments
• Several client sites on one reseller-style box
• A Node.js/API backend for a mobile or web app
• A Docker setup running multiple containers or microservices
• A database-heavy app (analytics, reporting, search indexing)

Each of these stresses a different resource first. A brochure site runs out of nothing until traffic spikes. A WooCommerce store runs out of RAM. A Docker host runs out of both RAM and disk. Sizing by workload, not by "what sounds like a good number," is the whole trick.

RAM: what's actually eating it

RAM usage on a web server isn't one number, it's a stack of processes that all want their own slice:

• PHP-FPM workers — each concurrent PHP request holds a worker in memory, typically 40-80MB per worker for WordPress with a handful of plugins.
• MySQL/MariaDB's InnoDB buffer pool — this is usually the single biggest consumer on a database-backed site, and it's the first thing that gets starved on a cheap plan.
• A cache layer — Redis or Memcached, if you're running one, needs its own headroom on top of everything else.
• The OS and web server itself — Nginx or Apache, plus systemd and background services, easily takes 300-500MB before your app has done anything.

If you've ever watched a WordPress site fall over during a traffic spike with no obvious error, check free -h first. Nine times out of ten it's PHP-FPM workers piling up because there wasn't enough RAM to run as many of them as the traffic needed, so requests queued and timed out.

vCPU: cores matter less than people assume

A single PHP request runs on one core. It doesn't matter if your VPS has 8 vCPUs — one page load uses one of them. More cores help when you have concurrent requests, not when a single page is slow. If one page load feels sluggish, that's usually a code or database problem, not a CPU count problem.

Where core count genuinely matters:

• Handling many simultaneous visitors (concurrency, not raw speed per request)
• Background jobs running alongside web traffic — cron imports, backups, image processing
• Multi-container Docker setups where each container wants its own share

Also watch for CPU steal time on budget shared VPS plans. Run top and look at the %st column — if it's consistently above a percent or two, the host is oversold and other tenants are eating your promised CPU cycles. No amount of "upgrading vCPU count" on that same host fixes a noisy-neighbor problem; you need a plan on infrastructure that isn't oversold, which is worth asking your host about directly.

Disk: size is the least important number

Everyone sizes disk by "how much stuff do I have," and that's the wrong first question. The two that matter more:

• IOPS/throughput — an NVMe-backed plan and a spinning-HDD-backed plan with the same GB number perform completely differently under database load. MySQL doing constant small writes is where slow disk shows up as slow queries, not as a full disk warning.
• Headroom for backups and snapshots — a lot of people size disk for their current files and databases, forget that on-server backups, log rotation, and package caches also live there, and end up hitting "No space left on device" while showing 40% free in a dashboard that isn't counting inodes or a reserved backup partition correctly.

Rule of thumb: whatever your actual data (files + database) adds up to, plan for at least double that in allocated disk if you're keeping any local backups or snapshots.

A starting-point sizing table

Treat this as a floor, not a ceiling — traffic spikes, plugin bloat, and "just one more site on this box" push every one of these numbers up over time.

The mistakes that actually cost people money or downtime

• Maxing out RAM but keeping 1 vCPU. A big buffer pool doesn't help if the single core is saturated the moment two visitors load a page at once.
• Not budgeting for backup/snapshot storage. The disk fills up quietly until a deploy or a WordPress update fails mid-write.
• Ignoring bandwidth caps on cheap plans. A video-heavy or high-traffic site can hit a transfer cap long before it hits CPU or RAM limits, and overage billing surprises people.
• Sizing for average traffic, not peak traffic. A WooCommerce store during a sale, or a site that gets a sudden social media spike, needs headroom for the worst day, not the typical Tuesday.
• Assuming "more expensive plan" always means "more real resources." On oversold shared infrastructure, a bigger plan number doesn't fix CPU steal time or noisy neighbors — check actual availability, not just the label on the tier.

When to scale up vs when to scale out

Vertical scaling (a bigger VPS) is the right move until you're paying for a plan that's mostly idle 90% of the time to survive the other 10%. At that point — recurring traffic spikes, a store that outgrows a single server during sales, or an app that needs to stay up during maintenance — it's usually cheaper and more resilient to move to a small load-balanced setup (see our guide on HAProxy load balancing) than to keep buying bigger single boxes.

Check what you're actually using before you upgrade

If you're already running a server and trying to decide whether to size up, don't guess — measure:

free -h                 # RAM used vs available
top                      # live CPU per process, check %st for steal time
df -h                    # disk space by partition
df -i                    # inode usage, separate from disk space
iostat -x 2 5            # disk I/O wait and throughput over time
vmstat 2 5               # quick view of CPU, memory, and I/O together

Run these during normal traffic and during your busiest hour, not just once when the server is idle. A server that looks fine at 3am and falls over at 9am has a peak-load problem, not an average-load problem, and the fix is sizing for the peak.

Most VPS providers, including Getwebup, let you resize a plan (more RAM or vCPU) with a reboot rather than a full migration — so it's fine to start a little lean and scale up once you have real usage data, rather than over-provisioning from day one on a guess.

Prevention: revisit sizing before it becomes an emergency

Set a calendar reminder to check resource usage every few months, especially after adding a new site, plugin, or feature. The pattern that causes 2am outages almost always looks the same: the server was sized correctly a year ago, three things got added since, and nobody re-checked whether the plan still matches the workload.