When you open Vultr’s deploy screen, you’re presented with a grid of plans — $6, $12, $24, $48 per month — each with different RAM, CPU, and storage specs. If you’re new to servers, these numbers don’t mean much yet.
This article explains what they actually mean for WordPress, and gives you a clear starting point.
The Three Resources and What They Do
RAM — The One That Runs Out First
RAM (Random Access Memory) is where your server stores the data it’s actively using. Every WordPress page request requires PHP to run, which consumes RAM. Every database query holds results in RAM. Redis object cache lives in RAM. The Nginx worker processes use RAM.
When RAM fills up, one of two things happens: the Linux kernel kills the process using the most memory (usually PHP-FPM), or the server starts using swap — disk space treated as overflow RAM.
RAM is almost always the first resource to run out on a WordPress VPS. CPU and disk are rarely the primary bottleneck for a small-to-medium site.
Practical RAM guidelines for WordPress:
| Scenario | Recommended RAM |
|---|---|
| Learning / single test site | 1GB |
| 1–2 small WordPress sites | 1–2GB |
| 3–5 sites with Redis + Nginx cache | 2–4GB |
| 6+ sites or medium-traffic site | 4GB |
| Large database (10k+ records) | 4GB minimum |
| High-traffic production site | 8GB+ |
CPU — Rarely the Bottleneck
CPU cores handle computation — running PHP, processing database queries, executing scripts. For a WordPress site with proper caching (Nginx FastCGI cache + Redis), most page requests are served from cache and never reach PHP. CPU load stays low.
Where CPU becomes relevant:
- Sites with heavy background processes (WooCommerce order processing, large imports)
- Sites generating pages dynamically without cache (every request hits PHP)
- Running multiple resource-intensive operations simultaneously
For the stack in this series — Nginx FastCGI cache + Redis — a single vCPU handles a surprisingly large amount of traffic. Start with 1 vCPU. Monitor. Upgrade if sustained CPU load stays above 80%.
Storage — Disk Space
SSD storage holds your files, databases, and logs. For a WordPress site:
- WordPress core: ~50MB
- Plugins and themes: 100–500MB depending on what you install
- Uploads (images, files): grows over time
- Database: typically 50MB–2GB for a content site
- Log files: can grow surprisingly large if not managed
Entry plans (25–55GB SSD) are enough for most WordPress setups. The exception: sites with large media libraries or databases. Monitor disk usage with df -h regularly.
What Happens When RAM Runs Out — A Real Story
My price comparison site had tens of thousands of product records synced from affiliate APIs. Each page load required PHP to query the database, process the results, and generate the page. Even with caching, the cache miss rate was high because the product catalog was constantly updating.
On a 4GB VPS, the server ran fine with low traffic. When crawlers or traffic spikes hit, RAM filled up. PHP-FPM processes got killed. The site returned 502 errors.
My first response was to add more RAM — move to a larger Vultr plan. That helped temporarily. Then I moved to Google Cloud for more headroom. The performance was good. The cost was not.
The actual problem wasn’t the hardware. It was the architecture. WordPress + a relational database is not the right tool for serving tens of thousands of semi-static product pages at scale. The solution wasn’t more RAM — it was rebuilding the site in a framework that didn’t generate pages dynamically.
That experience is what led me to Astro.
About Swap — Useful but Not a Solution
Swap is disk space the Linux kernel uses as overflow when physical RAM is full. You can add it to any server:
# Create a 1GB swap file
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfileSwap keeps your site alive when RAM runs out — instead of crashing, the server continues by using disk as slow RAM. This is genuinely useful. I’ve used swap on production servers.
The limitation: disk I/O is orders of magnitude slower than RAM. When your server is using significant swap regularly, page load times increase noticeably, and the server feels sluggish. You can see swap usage with:
free -mIf the Swap used column shows consistent activity — not just occasional spikes — that’s the signal to upgrade RAM or reconsider your architecture.
Swap is a safety net and an early warning system. Use it. Don’t rely on it.
The Vultr Plan I’d Start With
For this series — learning VPS, setting up WordPress, running a few small sites:
Start with the $12/month plan: 1 vCPU, 2GB RAM, 55GB SSD.
The $6/month plan (1GB RAM) works for learning but is tight once you have WordPress, Nginx, PHP-FPM, MariaDB, and Redis all running simultaneously. A WordPress admin dashboard reload can push a 1GB server to swap temporarily.
2GB RAM gives you comfortable headroom for the entire setup in this series — including Redis object cache — plus room for 2–3 small WordPress sites.
When you’re ready to add more sites or see consistent RAM pressure: upgrade to 4GB. On Vultr, you can resize the plan from the control panel without rebuilding the server.
How to Monitor Resources Once You’re Running
After your VPS is set up, check these regularly:
# RAM and swap usage
free -m
# Disk usage
df -h
# Live process monitor — CPU and RAM per process
htop
# Check if PHP-FPM is consuming too much
ps aux --sort=-%mem | grep php-fpm | head -10Part 8 of this series covers monitoring in more detail — what numbers to watch for and what they mean. For now, free -m and df -h after each setup step are enough to confirm you’re not running into limits during the build.