Hosting Multiple Websites on One Budget VPS: Nginx Server Blocks, PHP-FPM Pools, and RAM Planning

One budget VPS can comfortably host several small websites — a personal blog, a client portfolio, a wiki, and a status page — for the price of a single $6–$10/month plan. The catch is isolation. If two sites share one server without separation, one compromised script or one runaway process can take down everything. This guide covers how to structure nginx and PHP-FPM so multiple sites share the hardware safely, and how much RAM to budget per site.

When It Makes Sense to Share a VPS

Sharing one VPS across sites makes financial sense when the sites are low-traffic and non-critical: personal projects, staging environments, small business brochures, and internal tools. It stops making sense when a site becomes a resource hog — sustained high traffic, heavy cron jobs, or large media libraries — because one tenant then degrades the others. The general rule: if every site on the box fits in a single shared-hosting account, they fit on one small VPS with proper separation.

The Three Layers of Isolation

A secure multi-site setup on a budget VPS uses three layers of separation:

• Nginx server blocks: one server block per domain, each pointing at its own document root and its own log files.
• Separate PHP-FPM pools: one pool per site with its own user, socket, and memory limits, so a runaway script in one site cannot exhaust the others.
• Separate filesystem users: each site runs as its own system user with permissions limited to its own directory.

This is the same isolation model shared hosts use, just on a smaller scale — and it costs nothing extra beyond the setup time.

How Much RAM Per Site

Memory is the resource that runs out first on a shared VPS. PHP-FPM workers are the biggest consumer: each worker reserves 30–60 MB, and a WordPress site commonly needs 4–6 workers under load. The table below shows realistic budgets for a typical setup with nginx and a page cache enabled.

Add a page cache (nginx fastcgi_cache or a small Redis instance) and most requests never touch PHP at all, which stretches these budgets considerably. A cached WordPress site that serves 90% of requests from memory uses a fraction of the PHP pool capacity.

Setting Up the Pools: A Quick Walkthrough

On Ubuntu or Debian with nginx and PHP-FPM, the setup follows the same pattern per site. Create a user, a document root, and a pool file:

• Create the site user and directory: useradd -m site1, mkdir /var/www/site1
• Add a pool in /etc/php/8.3/fpm/pool.d/site1.conf with its own listen socket and pm.max_children limit (2–4 is a safe start on 1–2 GB RAM)
• Add an nginx server block for the domain pointing at the site root and the site’s socket
• Set open_basedir in the pool to the site’s own directory
• Restart php-fpm and nginx, then check ps aux | grep php-fpm to confirm each site runs under its own user

The nginx server blocks and PHP-FPM pool files are plain text configs, so the whole setup costs nothing beyond the server itself — no control-panel license required.

What to Watch For

Monitor memory headroom weekly with free -m and check per-pool usage. If one site routinely consumes its entire pool, that site is the candidate for its own VPS or a caching upgrade. Backups also need a plan: keep each site’s files and database in its own backup job, and store copies off-server so a compromised box does not take the backups with it.

A Realistic Example: Two WordPress Sites on 2 GB

A 2 GB / 2 vCPU VPS at $10–$14/month can run two WordPress sites with room to spare if you plan the numbers. Each site gets a PHP-FPM pool capped at two workers with a 128 MB per-request limit — that is roughly 512 MB of worst-case PHP usage for both. MariaDB with a 256 MB buffer pool adds another ~300 MB. nginx, the OS, and a file-based page cache sit at about 150–200 MB. Total worst case: around 1.2 GB, leaving 800 MB of headroom for traffic spikes, cron jobs, and a nightly backup. The same math with three or four static or cached sites fits comfortably on 1 GB.

The failure mode to avoid is unbounded pools. A WordPress plugin that leaks memory in a single pool with no cap can consume the whole box. Setting pm.max_children and request_terminate_timeout on every pool turns a server-wide outage into a single-site slowdown — exactly the isolation you are paying for.

Certificates, Cron, and Other Shared Services

Three shared services need deliberate planning in a multi-site setup. First, TLS certificates: use a single certbot instance with one nginx snippet per site rather than one cron job per site — it simplifies renewal and avoids certificate conflicts. Second, cron jobs: give each site its own crontab under its own user, and stagger heavy jobs (backups, cache warming, log rotation) so they do not all fire at 3 AM and spike memory together. Third, mail: if you send transactional mail from multiple sites, route each through its own authenticated sender or a single properly configured relay — shared mail configurations are a common source of deliverability problems.

If you are still choosing a host for your first multi-site setup, compare entry-level plans on our budget VPS comparison table — look for 2 GB RAM plans in the $10–$14 range, which give you room to run several sites without upgrading in month one.

Related Articles：

Benchmarking a Budget VPS Before You Commit: Tests That Separate Real Specs from Marketing Low Cost VPS Hosting in 2026: What $5-$15/Month Plans Actually Deliver VPS vs Shared Hosting in 2026: Why Paying $5/Month More Saves You Time, Money, and Performance Budget VPS RAM Guide: How Much Memory You Actually Need in 2026