A static site is the cheapest workload you can run on a VPS, and the numbers make the case without exaggeration. A single nginx worker on one vCPU delivers tens of thousands of static requests per second. A site with 100,000 monthly visitors averages 3–4 requests per second across a day. The server is not the constraint at that scale; DNS resolution and page weight are.
The important question is not whether a cheap server can handle it — it can — but how to size the plan correctly, serve it efficiently, and know exactly when to change something.
Static vs Dynamic: Where the Resources Go
| Metric | Static site | WordPress | Ratio |
|---|---|---|---|
| Idle RAM | 30–80 MB | 400–700 MB | ≈10× |
| Requests/sec (1 vCPU) | 5,000–20,000 | 50–300 | ≈50× |
| Disk per page | 5–50 KB | DB row + PHP overhead | — |
| CPU per request | near zero | process + query | — |
| Cache layer needed | no | usually yes | — |
The gap comes from work-per-request. A dynamic request boots PHP, opens a database connection, runs queries, and renders HTML. A static request reads a file and hands it to the network stack. Eliminating that work eliminates the resource ceiling.
What 100,000 Monthly Visitors Actually Requires
Break the traffic down before sizing hardware:
- 100,000 views/month ≈ 3,300/day ≈ 4 requests/second average
- A realistic 5× peak ≈ 20 requests/second
- Average static page ≈ 50 KB compressed ≈ 1 MB/s at peak
- Bandwidth ≈ 5 GB/month plus assets
A 512 MB / 1 vCPU plan handles this with headroom measured in orders of magnitude. The genuine limits are the 1 TB bandwidth allowances common on budget plans and the plan’s disk — both generous for text-heavy sites. Our budget VPS comparison breaks down which plans include adequate transfer for content sites.
Serve Static Files Properly
Default nginx configuration works, but three settings materially improve performance on small servers:
sendfile on; # kernel-level file transfer
tcp_nopush on; # batch response headers
gzip_static on; # serve pre-compressed .gz filesgzip_static is the highest-value change: pre-compress assets at build time and nginx serves them without spending CPU per request.
When Static Stops Being the Right Choice
Static sites are the correct answer until you need one of these:
- User accounts, logins, or sessions
- Server-side rendering with per-user data
- Frequent content edits published by non-technical users
- Real-time features such as chat or live search
If none apply, static hosting cuts hosting cost to the smallest plan a provider sells. If some apply, a hybrid works well: static marketing pages on the VPS, dynamic application on a separate small instance.
The Build Pipeline Is the Real Cost
Static hosting is cheap; the build step is where effort lives. A typical workflow:
- Generate with Hugo, Eleventy, or Astro — sub-second builds for most sites
- Output to
/var/www/site, served directly by nginx - Deploy with
rsync -az --delete public/ user@vps:/var/www/site/ - Keep the previous release in a numbered directory for rollback
A site rebuilt in seconds and deployed by rsync needs no container runtime, no database service, and no application server — which is precisely why its memory footprint stays in the tens of megabytes.
Cost Reality Check
Running the same content on WordPress requires 512 MB minimum and comfortably 1 GB, with caching plugins and tuning. The static version fits on the smallest plan a provider offers and leaves headroom. Over a year the difference is often $30–$60 — small in absolute terms, but it is money spent on overhead rather than output.
Choosing a Plan Without Overspending
Static workloads reward the cheapest competent tier. The relevant specs are narrow:
- RAM — 512 MB is sufficient; more changes nothing
- Storage — 10–20 GB holds thousands of pages and images
- Bandwidth — the only spec worth upgrading for on media-heavy sites
- CPU — one shared vCPU is rarely a limiting factor
A cost trap appears when buyers size static sites as if they were application servers, paying for 4 GB of RAM and 2 vCPUs that sit idle. The correct approach is to buy the smallest plan, monitor bandwidth, and upgrade only when transfer approaches the allowance.
Adding a CDN Changes the Equation
A free CDN tier in front of a static site reduces origin requests to a small fraction of total traffic. HTML is cached at the edge, so the VPS handles only cache misses and deploy invalidations. The effect on a fledgling content site is that the 1 TB allowance on a budget plan becomes effectively unbounded for practical purposes, and p95 latency improves because pages are served from locations near visitors.
With a CDN in place, the correct plan for a static site is frequently the minimum configuration a provider sells — no upgrades required regardless of growth.
Deployment Without Downtime
The build-and-rsync model can briefly serve half-updated files. A versioned directory layout solves it cleanly:
rsync -az --delete public/ /var/www/releases/2026-09-24/
ln -sfn /var/www/releases/2026-09-24 /var/www/current
sudo nginx -t && sudo systemctl reload nginxThe symlink swap is atomic on Linux. Rolling back means pointing current at the previous release directory — no rebuild, no restore from backup.
Where the Real Costs Sit
The server is the smallest line item in a static site operation. Domain renewal runs $10–$15 per year, and a CDN free tier covers most small sites. Effort concentrates in templates, content, and build automation — areas where spending more on hosting delivers no benefit whatsoever.
That is the practical argument for static hosting: the workload’s ceiling is so far above the smallest plan that the decision becomes trivial. Compare entry tier specifications in our VPS comparison table, then put the savings into the parts of the site visitors actually see.
