{"id":957,"date":"2026-08-14T23:44:54","date_gmt":"2026-08-14T23:44:54","guid":{"rendered":"https:\/\/affordablevpsserver.com\/blog\/?p=957"},"modified":"2026-08-14T23:44:54","modified_gmt":"2026-08-14T23:44:54","slug":"multiple-websites-one-budget-vps-nginx-php-fpm","status":"publish","type":"post","link":"https:\/\/affordablevpsserver.com\/blog\/multiple-websites-one-budget-vps-nginx-php-fpm\/","title":{"rendered":"Hosting Multiple Websites on One Budget VPS: Nginx Server Blocks, PHP-FPM Pools, and RAM Planning"},"content":{"rendered":"
One budget VPS can comfortably host several small websites \u2014 a personal blog, a client portfolio, a wiki, and a status page \u2014 for the price of a single $6\u2013$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.<\/p>
When It Makes Sense to Share a VPS<\/h2>
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 \u2014 sustained high traffic, heavy cron jobs, or large media libraries \u2014 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.<\/p>
The Three Layers of Isolation<\/h2>
A secure multi-site setup on a budget VPS uses three layers of separation:<\/p>
Nginx server blocks:<\/strong> one server<\/code> block per domain, each pointing at its own document root and its own log files.<\/li>
Separate PHP-FPM pools:<\/strong> one pool per site with its own user, socket, and memory limits, so a runaway script in one site cannot exhaust the others.<\/li>
Separate filesystem users:<\/strong> each site runs as its own system user with permissions limited to its own directory.<\/li><\/ul>
This is the same isolation model shared hosts use, just on a smaller scale \u2014 and it costs nothing extra beyond the setup time.<\/p>
How Much RAM Per Site<\/h2>
Memory is the resource that runs out first on a shared VPS. PHP-FPM workers are the biggest consumer: each worker reserves 30\u201360 MB, and a WordPress site commonly needs 4\u20136 workers under load. The table below shows realistic budgets for a typical setup with nginx and a page cache enabled.<\/p>
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.<\/p>
Setting Up the Pools: A Quick Walkthrough<\/h2>
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:<\/p>
Create the site user and directory: useradd -m site1<\/code>, mkdir \/var\/www\/site1<\/code><\/li>
Add a pool in \/etc\/php\/8.3\/fpm\/pool.d\/site1.conf<\/code> with its own listen<\/code> socket and pm.max_children<\/code> limit (2\u20134 is a safe start on 1\u20132 GB RAM)<\/li>
Add an nginx server<\/code> block for the domain pointing at the site root and the site\u2019s socket<\/li>
Set open_basedir<\/code> in the pool to the site\u2019s own directory<\/li>
Restart php-fpm and nginx, then check ps aux | grep php-fpm<\/code> to confirm each site runs under its own user<\/li><\/ul>
The nginx server blocks and PHP-FPM pool files are plain text configs, so the whole setup costs nothing beyond the server itself \u2014 no control-panel license required.<\/p>
What to Watch For<\/h2>
Monitor memory headroom weekly with free -m<\/code> 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\u2019s files and database in its own backup job, and store copies off-server so a compromised box does not take the backups with it.<\/p>
A Realistic Example: Two WordPress Sites on 2 GB<\/h2>
A 2 GB \/ 2 vCPU VPS at $10\u2013$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 \u2014 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\u2013200 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.<\/p>
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<\/code> and request_terminate_timeout<\/code> on every pool turns a server-wide outage into a single-site slowdown \u2014 exactly the isolation you are paying for.<\/p>
Certificates, Cron, and Other Shared Services<\/h2>
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 \u2014 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 \u2014 shared mail configurations are a common source of deliverability problems.<\/p>