Static Sites on a Budget VPS: Serving 100,000 Visitors with 512MB of RAM

A single nginx worker on one vCPU serves roughly 10,000 requests per second of static files — HTML, CSS, JS, images — with memory usage in the tens of megabytes. A site with 100,000 visitors per month averages only 3–4 requests per second over a typical day. In other words, a $4/month VPS with 512 MB of RAM is not merely enough for a static site with that traffic; it is overkill by roughly three orders of magnitude. The bottleneck for such a site is never the server — it is the visitor’s connection, the DNS lookup, and how heavy you made the homepage.

The entire cost difference between a static site and a dynamic one comes down to one thing: a dynamic site runs application code and a database on every request, while a static site just reads files from disk. That is why moving from WordPress to a static generator is the single most effective way to cut hosting costs without touching performance. If you are comparing servers for the job, our comparison table shows which budget plans have the specs for static hosting at the lowest price.

Why Static Beats Dynamic on Small Servers

The numbers tell the story:

• Memory: a static site uses 30–80 MB total; the same content in WordPress needs 400–600 MB once PHP and MySQL are running.
• Attack surface: no PHP, no database, no admin panel to brute-force — nothing to patch except the web server.
• Reliability: a crashed application process cannot take down a site that is just files on disk.
• Backups: the entire site is a folder; rsync or a git push is a complete backup.

The trade-off is that publishing becomes a build step instead of a save-and-hit-publish flow. For a blog, documentation site, landing page, or portfolio, that trade-off is invisible to visitors and worth thousands of dollars a year in avoided complexity. Contributors write in Markdown, the build runs unattended, and nobody ever logs into a database to fix a broken query.

A Server Config That Handles the Load

A minimal nginx configuration for a static site, with caching headers so browsers do the rest of the work:

server {
    listen 80;
    server_name example.com;
    root /var/www/example;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
        expires 7d;
        add_header Cache-Control "public, max-age=604800";
    }
    gzip on;
    gzip_types text/css application/javascript image/svg+xml;
}

That is the entire server configuration. No PHP-FPM pool, no database, no cache warming. Add HTTPS with certbot and the deployment is complete:

apt-get install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

Certbot renews the certificate automatically, and the whole stack — nginx plus TLS — typically idles below 40 MB of RAM. For extra headroom on a 512 MB plan, raise worker_processes to match your vCPUs and keep keepalive_requests at the default; the server will not break a sweat. If you want even more margin, put a free CDN in front and the VPS barely sees the traffic at all.

Keeping the Build Pipeline Cheap

The build step can run anywhere — it does not need the VPS at all. The cheapest setups are:

• A GitHub/GitLab repository with a CI job that builds and rsyncs to the server on every push.
• A cron job on the VPS that pulls the repo and rebuilds every hour, for sites that update rarely.
• A local build on your own machine, pushing only the output folder to the server.

A deploy script for the cron approach is short enough to fit in a crontab line:

0 * * * * cd /srv/site && git pull -q && hugo --quiet && rsync -a --delete public/ /var/www/example/

Tools like Hugo and Eleventy build a thousand-page site in seconds and emit plain HTML. The server never needs a compiler, a node runtime, or a database — which means the smallest, cheapest VPS plan from any provider will do. If you want managed infrastructure instead of assembling it yourself, Database Mart offers budget-friendly hosting plans that handle static and small dynamic sites alike, and the specs of their entry-level plans are in our comparison table for a final sanity check.

When Static Stops Being Enough

Move back to a dynamic stack only when you genuinely need per-visitor personalization, user accounts, or live data — not for comments (use a third-party service) and not for search (use a static indexer). Even then, consider a hybrid: keep the marketing pages and blog static, and run the dynamic application on a subdomain or a separate small VPS. That way the 99% of traffic that hits static pages never touches the expensive part of the stack. Until that day, a 512 MB static VPS will serve 100,000 visitors a month with RAM to spare, and your hosting bill stays at the bottom of the market. Start with the smallest plan, measure with a monitoring tool, and upgrade only if the logs tell you to.