Hosting Several Small Sites Behind One Reverse Proxy on a Budget VPS
TL;DR: Freelancers and side-project builders often outgrow one-site shared hosting before they need a fleet of servers. One modest VPS plus a reverse proxy can serve multiple low-traffic sites safely if you isolate apps, certificates, and backups. Size the box with Affordable VPS Server guidance in mind, then design the proxy layer before you paste five unrelated stacks onto root.
When one cheap VPS beats five shared accounts
Shared hosting panels feel simple until you juggle unrelated PHP versions, cron collisions, and opaque neighbor noise. A single budget VPS gives you predictable CPU shares and the freedom to run mixed stacks—static sites, a small Node app, a WordPress instance—without paying for five control panels. The tradeoff is responsibility: you own updates, firewall rules, and the blast radius when something misbehaves.
This pattern fits portfolios, staging-plus-production pairs, and client microsites that sleep most of the day. It does not fit heavy analytics warehouses or untrusted multi-tenant SaaS. If any one site could soak the CPU, give it its own machine or at least hard cgroup limits before you celebrate the monthly savings.
Reverse proxy as the front door, not an afterthought
Put Nginx or Caddy on ports 80/443 and keep application servers bound to localhost. Each hostname gets a server block that forwards to a unique upstream port or socket. That separation lets you renew certificates in one place and hide language runtimes from the public internet.
Name upstreams clearly (app_portfolio, app_docs) instead of raw ports in tribal memory. When you migrate a site later, you edit one upstream definition instead of hunting magic numbers across configs. Log access per virtual host so one noisy bot campaign does not look like “the whole VPS is dying.”
Isolation checklist before the second site goes live
- Separate system users or containers per app so a compromised plugin cannot write into every document root.
- Unique databases and passwords; never reuse the panel root credential across projects.
- Per-site systemd units with restart limits so a crash loop cannot peg all cores forever.
- Disk quotas or dedicated volumes for upload-heavy sites that might fill the disk overnight.
Skipping isolation is how a forgotten WordPress install takes down your client’s brochure site at 2 a.m.
Certificates, HTTPS, and hostname hygiene
Automate Let’s Encrypt per hostname and test renewal with a dry run after the second site is added—not six months later. Wildcard certificates are convenient when you control many subdomains on one project; they are a poor fit for unrelated client domains that come and go.
Force HTTPS at the proxy, redirect www consistently, and keep application “site URL” settings aligned. Mixed signals between the proxy and the app create redirect loops that look like outages. Document the canonical host for each site in a single inventory file on the server.
Resource math on a small plan
Budget VPS nodes often ship with 1–2 GB RAM. Two PHP-FPM pools plus MySQL will eat that quickly if you copy shared-hosting defaults. Lower PHP children, enable a modest OpCache, and put a page cache in front of WordPress. Static sites barely register; dynamic apps need intentional ceilings.
Watch steal time and load averages for a week after each new hostname. If steal is high on a noisy neighbor hypervisor, resizing vertically may help less than moving to a quieter host—price is not the only affordability metric. Disk I/O matters too: a logs directory growing without rotation can stall every site sharing the volume.
Backups that understand multi-site reality
One tarball of /var/www is not a restore plan. Back up each site’s files, its database, and the proxy config as related units. Label restore drills by hostname. When a plugin update ruins site B, you should not have to roll back site A’s content to yesterday.
Store copies off-box. A second cheap object-storage bucket beats a second folder on the same SSD. Encrypt sensitive dumps; client sites often contain PII even when the public pages look trivial.
Deploy habits that keep the proxy boring
Prefer atomic releases per site: build into a new directory, flip a symlink, reload only the affected upstream. Avoid SSH-as-IDE editing on production document roots for five different clients. One fat-fingered sed across /var/www is an outage anthology.
Keep a minimal inventory markdown on the box and in your laptop notes: hostname, upstream port, app user, database name, TLS renewal method, and owner contact. When a certificate mail arrives at 6 a.m., you should not reverse-engineer which project owns which vhost.
Security updates deserve a cadence. Unattended upgrades for packages are fine if you still reboot into a maintenance window and curl each hostname afterward. Multi-site boxes fail quietly when only the first vhost gets tested after a kernel update.
Finally, decide an admission policy: how many sites, what stacks, what traffic ceiling. Turning every friend request into another vhost is how a tidy reverse-proxy workshop becomes an unmaintainable hostel.
A reverse-proxied budget VPS is a compact workshop, not a infinite hotel. Keep apps isolated, certificates boring, and capacity honest. When you are ready to pick or compare a right-sized plan, start at affordablevpsserver.com and design the proxy map before the first deploy script runs.
