A $5 VPS in 2026 typically buys 1–2 GB of RAM, 1–2 shared vCPUs, 20–40 GB of NVMe, and 1–2 TB of transfer. That is genuinely enough to run a production website, several bots, or a small application stack. It is not enough to run them all at once with no tuning. This is what the hardware actually absorbs, with the break points measured rather than guessed.
What a $5 Plan Handles Comfortably
- A WordPress or Ghost site with a page cache, serving 20,000–50,000 monthly visits.
- A static site or documentation site with effectively unlimited practical traffic behind a CDN.
- Two to four Discord or Telegram bots, or a small Python or Node.js API handling a few requests per second.
- A WireGuard VPN endpoint for a household, plus a jump host.
- A self-hosted monitoring stack, a Git remote, and a notes sync server sharing one box.
- A small MySQL or PostgreSQL database under light write load, alongside an app.
The common thread is that none of these sustain high CPU or heavy random IO for long stretches. Burst capacity on modern shared hosts is generous; it is sustained usage that triggers throttling or noise from neighbours.
Where a $5 Plan Starts to Strain
| Signal | What it means | Practical response |
|---|---|---|
| Load average above vCPU count for 15+ min | CPU is the wall | Cache, queue, or upgrade cores |
| Swap usage climbing past ~30% | RAM is the wall | Trim services or add RAM |
| OOM killer terminating MySQL/PHP | Hard RAM ceiling hit | Upgrade, do not tune around it |
| Disk above 85% full | Writes will fail soon | Clear logs or add storage |
| Egress approaching the monthly cap | Overage bills ahead | Add a CDN or raise the tier |
| Steal time above 5–10% | Neighbour contention | Move provider or tier |
The first three signals are the ones that matter. A site that swaps steadily will feel fine at low traffic and collapse the moment a crawler or a campaign lands. If you are seeing that pattern, our piece on why swap hides a real memory shortage explains why adding swap only delays the problem.
Six Tuning Steps That Buy Real Headroom
- Put a page cache in front of the application — static HTML saves 80–95% of PHP executions.
- Serve images and static assets through a CDN so egress and CPU both drop.
- Move the database to tuned defaults: innodb_buffer_pool_size near 50–60% of RAM, and log rotation capped.
- Replace Apache with Nginx or a lightweight front end; the memory difference is measurable at 1–2 GB.
- Enable zram or a swapfile on NVMe as a safety net, not as capacity.
- Cap log growth with logrotate and delete old journal entries on a schedule.
Applied together, these steps routinely let a 1 GB plan serve traffic most people would size as needing 4 GB. They also raise the ceiling on how much abuse the box tolerates before it falls over.
Realistic Concurrency: How Many Simultaneous Users Fit
Concurrency is the number that predicts downtime far better than monthly visitors. Each dynamic PHP request on a well-tuned stack costs roughly 30–80 MB of RAM for its lifetime. With 1 GB total and about 600 MB available to the web tier after the OS and database, that is somewhere between 8 and 20 simultaneous dynamic requests — provided the cache is miss-only traffic and pages render in under 300 ms.
| Plan size | RAM for web tier | Concurrent dynamic requests | Cached-request ceiling |
|---|---|---|---|
| 1 GB | ~450 MB | 8–12 | 150–300/sec |
| 2 GB | ~1.1 GB | 18–30 | 300–600/sec |
| 4 GB | ~2.4 GB | 40–70 | 600–1,200/sec |
Raise the cache hit ratio and the cached-request ceiling applies to almost all traffic. Lower it and the concurrency numbers above are what a traffic spike has to climb over. This is why cache configuration, not plan size, is usually the first thing to fix when a $5 server feels slow.
Upgrade Triggers, With Numbers
| Upgrade when | To what | Why |
|---|---|---|
| Sustained load > 2× vCPU count | 2–4 dedicated cores | Shared burst is exhausted |
| OOM kills more than once a month | 4 GB RAM | Tuning is no longer the constraint |
| Constant swap activity under normal load | 4 GB RAM | Working set exceeds 1–2 GB |
| Database > 10 GB or write-heavy | Separate DB VPS | IO isolation |
| Monthly egress near the cap | Higher-transfer tier | Overage costs exceed the difference |
The honest test is not “is it slow?” but “which resource graphs are pinned?” Pinning CPU means add cores. Pinning RAM means add memory. Nothing pinned but users complain means the problem is upstream of the hardware.
What the $5 Tier Buys You in Practice, Month by Month
Budget plans fail slowly before they fail suddenly. The pattern below is what a steadily growing site looks like across a year on a $5 plan, and it is the reason the upgrade triggers above are worth watching rather than reacting to.
| Month | Typical growth | What you notice first |
|---|---|---|
| 1–3 | Launch, low traffic | Nothing — plenty of headroom |
| 4–6 | Cache warms, traffic doubles | Occasional slow page, fine after tuning |
| 7–9 | Plugins and logs accumulate | Disk climbing, RAM steady |
| 10–12 | Traffic + a campaign or crawler | Swap active, brief slow windows |
| 13+ | Compounded growth | OOM kills or sustained high load |
None of these stages require an emergency migration if you watch the right metric at each stage. The failure mode people actually hit is ignoring stage four because the site still loads fast most of the time — then hitting stage five during a sale or a viral post.
If your graphs show a permanently pinned resource, our budget VPS plans start at roughly twice the $5 tier and remove the constraint for the price of one coffee a week. If they do not, keep the $5 plan — it is doing its job.
