How to Choose VPS Specs:CPU, RAM and Storage for Your Workload

Size a VPS by working out how much memory your software needs at peak, how much CPU your busiest uncached requests use, and how much fast storage your data and growth require, then add headroom. Memory is the resource most often under-sized; when a server runs out of RAM, it slows sharply or the system starts killing processes.

There is no universal formula, but the method below gives a sensible starting point and tells you how to correct it with real data.

Step 1: List what will run on the server

Write down every component and its rough memory needs:

• Operating system and basic services.
• Web server (Nginx, Apache or LiteSpeed).
• PHP-FPM workers (or Node.js, Python application processes).
• Database (MySQL or MariaDB), usually the largest memory consumer on its own.
• Caching (Redis or Memcached).
• Control panel, if any; cPanel and Plesk add their own services.
• Mail server, if hosted on the same VPS.
• Background jobs, queues and cron tasks.

Step 2: Estimate memory

Memory adds up per component. For a PHP application:

PHP memory ≈ number of PHP workers × average memory per worker

If each PHP-FPM worker uses around 60–120 MB under a WordPress or Laravel workload, ten workers need roughly 0.6–1.2 GB. Measure your real per-process usage when you can.

Database memory is mostly the InnoDB buffer pool. Ideally it holds the frequently used part of your data. See MySQL and MariaDB performance tuning.

Then add the OS, web server, cache, control panel and a margin of 20–30%. As rough guidance:

Workload	Typical starting point
One small WordPress site, no panel	1–2 GB RAM
Several WordPress sites, or one busy site	2–4 GB RAM
WooCommerce store with steady orders	4–8 GB RAM
VPS with cPanel/WHM hosting several sites	4 GB RAM or more
Custom app with database and Redis on one server	4–8 GB RAM

These are starting points, not guarantees. Measure and adjust.

Step 3: Estimate CPU

CPU need depends on how much work each uncached request does and how many happen at once.

• Content sites with good page caching use little CPU per visit.
• Stores, membership sites, search-heavy sites and APIs use more.
• Image processing, imports, reports and video encoding create CPU spikes.

Two vCPUs suit many small production workloads; four or more for busy stores and applications. If the server's load regularly exceeds its number of vCPUs, it is short of CPU. See Linux load average, CPU and memory explained.

Step 4: Estimate storage

• Data: website files, uploads, databases, email and logs.
• Backups: if you keep local copies (keep off-server copies too).
• Growth: at least a year ahead.
• Free space margin: keep 20% or more free; full disks cause crashes and database corruption.

Storage type matters as much as size: databases and busy sites benefit greatly from NVMe SSD storage. See NVMe vs SSD vs HDD.

Step 5: Consider bandwidth and location

Check the monthly transfer allowance against your traffic, and choose a data centre close to your users for lower latency.

Step 6: Start sensibly and measure

1. Choose a plan that covers your estimate with headroom.
2. Install monitoring from day one; see server monitoring basics.
3. After a few weeks of real traffic, check memory, swap, CPU load, disk I/O and space at peak times.
4. Resize up or down based on data, not guesses.

Worked example: sizing a VPS for a growing shop

A WooCommerce shop moving from shared hosting. Its current usage and plans:

• About 40,000 visits a month, peaking at around 150 concurrent visitors during campaigns.
• Database: 1.2 GB, growing about 300 MB a year.
• Media: 9 GB.
• No control panel wanted; a developer will manage the server.

The estimate:

Component	Memory
OS and services	0.5 GB
Nginx	0.1 GB
PHP-FPM: 16 workers × ~90 MB	1.5 GB
MariaDB buffer pool (data plus growth)	2 GB
Redis object cache	0.25 GB
Headroom (about 25%)	1 GB
Total	about 5.5 GB → choose 6–8 GB

CPU: 4 vCPUs to handle campaign peaks of uncached checkout traffic. Storage: 9 GB media + 1.2 GB database + logs + room to grow over two years → 40–60 GB of NVMe.

After a month on the new VPS, monitoring shows memory peaking at about 5 GB and CPU at 60% during the biggest campaign, so the estimate holds with headroom. If campaigns grow, upgrading CPU and RAM later is a quick change.

Signs the VPS is too small

• Memory near 100% with swap in constant use.
• Out-of-memory events in the system log (processes killed).
• Load average consistently above the number of vCPUs.
• High I/O wait while the disk is busy.
• Slow responses at peak times that improve when traffic drops.

Signs it is larger than you need

• Memory usage, including caches, stays well below half.
• CPU is mostly idle even at peak.
• In that case, a smaller plan may save money, but leave room for traffic spikes.

Frequently Asked Questions

Is more CPU or more RAM more important?

For most web workloads, enough RAM comes first, because running out of memory causes severe slowdowns and crashes. Then add CPU for heavy dynamic traffic.

Does a control panel need extra resources?

Yes. Panels such as cPanel run additional services and need more memory and disk than a bare server.

How much swap should I have?

A modest amount as a safety net, not as extra RAM. See Linux swap space explained.

Compare VPS plans

With your estimate in hand, compare the ServerNeed VPS plans. For the fundamentals, see what is a VPS.

Sources

• PHP Manual: FPM configuration
• MariaDB documentation: InnoDB buffer pool
• WordPress.org: Requirements