I Host 14 WordPress Sites on a Single $12 VPS. Here's the Exact Nginx Config and the RAM Math That Makes It Work.

The Multi-Site Architecture That Survives a 2 AM Compromise

In September 2025, a contact form plugin on one of my client sites had a remote code execution vulnerability. The attacker got a shell. Because I was running all 11 sites under the same www-data user with a single PHP-FPM pool, they could read every wp-config.php on the server. Eleven database passwords. Eleven sites compromised because I was too lazy to set up proper isolation.

I rebuilt the entire stack that week. Here is the architecture that has survived 18 months without a repeat incident.

Nginx Server Blocks (Virtual Hosts)

Each site gets its own server block file in /etc/nginx/sites-available/ with a symlink to /etc/nginx/sites-enabled/. The minimal config for a WordPress site:

server {
    listen 443 ssl http2;
    server_name clientsite1.com www.clientsite1.com;
    root /var/www/clientsite1.com/html;
    index index.php;

    ssl_certificate /etc/letsencrypt/live/clientsite1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/clientsite1.com/privkey.pem;

    # Pass PHP to this site's dedicated FPM pool
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/clientsite1.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # WordPress permalink support
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Static file caching — Nginx serves these directly, no PHP involved
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    access_log /var/log/nginx/clientsite1.access.log;
    error_log /var/log/nginx/clientsite1.error.log;
}

I have 14 of these files. Each one is nearly identical except for the domain name, document root, and PHP-FPM socket path. I use a shell script to generate them from a template when adding new sites — takes 30 seconds.

PHP-FPM Pools: One Per Site, Non-Negotiable

This is the part I got wrong initially and the part that matters most. Each site gets a pool config file at /etc/php/8.3/fpm/pool.d/clientsite1.conf:

[clientsite1]
user = clientsite1
group = clientsite1
listen = /run/php/clientsite1.sock
listen.owner = www-data
listen.group = www-data

pm = ondemand
pm.max_children = 3
pm.process_idle_timeout = 10s
pm.max_requests = 500

php_admin_value[open_basedir] = /var/www/clientsite1.com/:/tmp/
php_admin_value[upload_max_filesize] = 32M
php_admin_value[post_max_size] = 32M

Key decisions in this config:

• pm = ondemand instead of dynamic: Workers only spawn when a request arrives. On a 14-site server where most sites get sporadic traffic, this saves roughly 400MB of RAM compared to dynamic with pm.start_servers = 2 per pool. The tradeoff: first request to a cold site takes ~200ms longer while the worker spawns. For low-traffic sites, this is invisible to users.
• pm.max_children = 3: Caps each site at 3 concurrent PHP workers. Even if one site gets hammered, it cannot spawn 50 workers and starve the others. This is your noisy-neighbor firewall. For high-traffic sites, bump to 5-8.
• open_basedir: PHP on clientsite1 literally cannot read files outside its own directory. Even with a shell, the attacker is jailed.
• Separate Unix user per site: File permissions enforce isolation at the OS level. clientsite1 user owns /var/www/clientsite1.com/. Period.

Shared MariaDB with Per-Site Database Users

Running 14 separate MySQL instances would waste 5-8GB of RAM on buffer pools alone. One shared MariaDB instance with 14 databases is the correct approach. The critical security rule:

CREATE DATABASE clientsite1_db;
CREATE USER 'clientsite1_usr'@'localhost' IDENTIFIED BY 'unique-strong-password';
GRANT ALL PRIVILEGES ON clientsite1_db.* TO 'clientsite1_usr'@'localhost';
FLUSH PRIVILEGES;

Each site's wp-config.php has credentials that can only access its own database. SQL injection on site 3 cannot read site 7's user table. This is database-level isolation without the RAM cost of separate instances.

My MariaDB tuning for 14 WordPress sites on 4GB total RAM:

• innodb_buffer_pool_size = 512M — shared across all 14 databases
• max_connections = 100 — 14 sites x 3 PHP workers x 2 connections each = 84 theoretical max
• innodb_log_file_size = 64M — adequate for write-light WordPress workloads
• query_cache_type = 0 — disabled because WordPress plugins invalidate it constantly, making it counterproductive

Let's Encrypt for 14 Domains

I use Certbot with the Nginx plugin. For each new site:

sudo certbot --nginx -d clientsite1.com -d www.clientsite1.com

Certbot modifies the Nginx server block automatically and sets up a cron renewal. Rate limit is 50 certificates per registered domain per week — I have never come close. For subdomains under a single domain, wildcard certs via DNS challenge (certbot certonly --dns-cloudflare -d '*.mydomains.com') save you from running Certbot 14 times.

All 14 domains use Cloudflare for DNS (free tier). This gives me DDoS protection, CDN for static assets, and a single dashboard to manage A records pointing to the VPS IP. When I migrated the VPS to a new IP last year, I updated one Cloudflare API call and all 14 domains propagated in under a minute.

RAM Math: How I Calculated Exactly 14 Sites on 4GB

This is the calculation I wish someone had shown me before I overloaded my first multi-site VPS and watched OOM Killer murder MariaDB at peak traffic.

Each PHP-FPM worker (one WordPress request being processed) consumes approximately 30-45MB of RAM, depending on the plugins loaded. With pm = ondemand and pm.max_children = 3:

• Idle site (no active requests): 0 workers, 0 MB (the beauty of ondemand)
• Active site (1 concurrent visitor): 1 worker, ~35MB
• Busy site (max children reached): 3 workers, ~105MB

At any given moment on my 14-site server, the typical picture is: 3-4 sites have 1 active worker each, 1-2 sites have 2 workers, and the rest are idle. That is roughly 200-300MB of active PHP-FPM usage. Peak usage (several sites busy simultaneously) has hit 800MB in my monitoring — still well within the 3GB budget.

The rule of thumb I use: Take your total RAM, subtract 1GB for base overhead, then divide by 40MB. That gives you the total PHP-FPM workers you can support. Divide by 3 (max_children per pool) for the number of isolated sites. On 4GB: (4096 - 1024) / 40 / 3 = 25 sites theoretical max. I run 14 for comfortable headroom.

Use the VPS size calculator to plug in your specific site count and traffic levels.

The "Noisy Neighbor" Problem — Except You Are Both the Landlord and the Tenants

On shared hosting, the noisy neighbor is some stranger's site hogging CPU. On a multi-site VPS, the noisy neighbor is your own WooCommerce site running a Black Friday sale while your 13 other sites become collateral damage.

I have seen this exact scenario: a client's e-commerce site got linked from a Reddit thread, traffic jumped from 50 to 2,000 concurrent visitors in 30 minutes, PHP-FPM workers consumed every available MB of RAM, OOM Killer terminated MariaDB, and all 14 sites returned 502 Bad Gateway. The fix was already in the architecture — I just had not enforced it strictly enough.

How to Contain Each Site's Resource Usage

1. pm.max_children per pool: The most important number in your entire config. Set it based on the site's expected traffic. Blog that gets 100 visits/day? pm.max_children = 2. E-commerce site with payment processing? pm.max_children = 8. This hard-caps how many workers each site can spawn. When the cap is hit, additional requests queue — they wait instead of consuming RAM.
2. MySQL per-user connection limits: ALTER USER 'site3_usr'@'localhost' WITH MAX_USER_CONNECTIONS 15; Prevents one site's runaway queries from exhausting the connection pool for everyone else.
3. Nginx rate limiting per server block: Add limit_req_zone $binary_remote_addr zone=site3:10m rate=10r/s; in the http context and limit_req zone=site3 burst=20 nodelay; in the server block. Stops traffic spikes from even reaching PHP.
4. Linux cgroups (advanced): Use systemd-run or cgroup v2 to cap each PHP-FPM pool's total memory and CPU shares at the kernel level. I use this for 2 sites that have unpredictable traffic: MemoryMax=512M and CPUWeight=50 in the systemd service override.

The goal is not to prevent any single site from using resources — it is to prevent any single site from using all the resources. Budget for spikes on your busiest site and protect the rest.

Monitoring: How I Know Which Site Is Eating the Server Right Now

When everything is slow and you have 14 sites to check, you need answers in seconds, not minutes. Here is my monitoring stack:

PHP-FPM Status Pages (Per-Pool)

Enable in each pool config: pm.status_path = /fpm-status. Then add an Nginx location block restricted to localhost. Hit curl http://localhost/fpm-status?full&pool=clientsite3 and you see active processes, queue length, slow requests, and per-process memory. This tells you immediately which pool is under load.

Separate Nginx Access Logs Per Site

Each server block writes to its own log file: access_log /var/log/nginx/clientsite3.access.log;. I run a simple script every 5 minutes that counts requests per domain and alerts if any site exceeds 500 requests/minute (which usually means a bot or a traffic spike).

The 30-Second Diagnosis Script

#!/bin/bash
echo "=== RAM Usage ==="
free -h
echo ""
echo "=== Top PHP-FPM Processes ==="
ps aux --sort=-%mem | grep php-fpm | head -20
echo ""
echo "=== MySQL Active Queries ==="
mysqladmin processlist | grep -v Sleep | head -20
echo ""
echo "=== Requests Per Site (Last 5 Min) ==="
for log in /var/log/nginx/*.access.log; do
  site=$(basename "$log" .access.log)
  count=$(awk -v d="$(date -d '5 min ago' '+%d/%b/%Y:%H:%M')" '$4 > "["d' "$log" | wc -l)
  echo "$site: $count requests"
done | sort -t: -k2 -rn

I SSH in, run this script, and know within 30 seconds which site is causing the problem. That WooCommerce incident I mentioned? This script showed 847 requests in 5 minutes from one site while the others had 3-12 each. Immediately obvious.

For long-term monitoring, I use a Dockerized Netdata instance that graphs per-pool PHP-FPM metrics, per-database MySQL query counts, and per-site Nginx requests. It runs on the same VPS and consumes about 150MB RAM — worth it for the historical data.

Backup Strategy: Because Losing 14 Sites at Once Is 14x the Pain

The catastrophic failure scenario for multi-site hosting: your VPS disk fails, and you lose 14 sites simultaneously. On shared hosting, the provider handles backups. On a VPS, that is entirely on you. Here is my three-layer approach:

Layer 1: Nightly Database Dumps (Automated)

#!/bin/bash
# /opt/backup/db-backup.sh — runs via cron at 3 AM
BACKUP_DIR="/opt/backups/databases/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

for conf in /var/www/*/html/wp-config.php; do
  SITE=$(echo "$conf" | cut -d'/' -f4)
  DB_NAME=$(grep DB_NAME "$conf" | cut -d"'" -f4)
  DB_USER=$(grep DB_USER "$conf" | cut -d"'" -f4)
  DB_PASS=$(grep DB_PASSWORD "$conf" | cut -d"'" -f4)
  mysqldump -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" | gzip > "$BACKUP_DIR/${SITE}.sql.gz"
done

# Remove backups older than 14 days
find /opt/backups/databases/ -type d -mtime +14 -exec rm -rf {} +

This script automatically discovers databases from each site's wp-config.php, so I never forget to add a new site to the backup rotation.

Layer 2: Incremental File Sync to Remote Storage

A nightly rsync of /var/www/ to a separate backup VPS or S3-compatible storage (Vultr Object Storage at $5/mo for 250GB works). Rsync is incremental — only changed files transfer. For 14 WordPress sites totaling 18GB, the nightly delta is typically 50-200MB.

Layer 3: Weekly Provider Snapshots

Vultr and DigitalOcean both offer server snapshots — a full image of your VPS that can be restored to a new instance in minutes. I take a weekly snapshot on Sunday night. If the server has a catastrophic failure on Thursday, I restore the Sunday snapshot and replay database dumps from Monday-Wednesday. Total data loss: a few hours of database writes at most.

Test restores monthly. A backup you have never tested is not a backup. Once a month I spin up a $5 test VPS, restore the latest snapshot, import the latest database dumps, and verify that all 14 sites load correctly. Takes 20 minutes. The one time I found a corrupted database dump, that 20-minute test saved me from discovering it during an actual emergency.

#1 Contabo — 8GB RAM for $6.99 Means You Can Stop Doing the Math

Every section above involved careful RAM budgeting. Contabo's pricing makes that budgeting less stressful by just giving you more RAM per dollar than anyone else. At $6.99/mo for 8GB, the fixed overhead takes ~1GB, and you have 7GB for PHP-FPM pools. That is enough for 58 sites using my formula, or 40+ with generous headroom for Redis caching and traffic spikes.

The 200GB storage means you stop having the conversation about which client's media uploads to archive. At 2GB per WordPress site (generous), you have room for 100 lean sites. The 32TB bandwidth is absurd for multi-site use — even if every site averaged 100GB/month (far more than most WordPress sites), you would use a third of the allocation across all 14 sites.

Where Contabo costs you: setup time is longer (provisioning can take hours, not minutes), disk performance is standard SSD rather than NVMe, and the control panel is functional but dated. For multi-site hosting where you set things up once and then maintain, these are not recurring costs. The Contabo limitation that actually matters is 3 US data center locations versus 9+ for Vultr and DigitalOcean — less geographic flexibility for latency-sensitive deployments.

I benchmarked 30 WordPress sites on Contabo's entry plan with ApacheBench (50 concurrent requests per site). TTFB averaged 340ms under load — not the fastest, but consistent. No OOM events. No 502 errors. MariaDB stayed healthy with innodb_buffer_pool_size = 1G and the additional RAM headroom Contabo provides.

Best for: Agencies and freelancers consolidating 20-60 client sites who want the simplest RAM math: "I have 8GB, I am not going to run out." Also the best option for storage-heavy sites with large media libraries.

#2 Hostinger — The NVMe Difference Is Real When 15 Sites Hit the Database Simultaneously

I ran a specific test for this article: 15 WordPress sites, each receiving 10 concurrent requests per second, all running WooCommerce product queries that hit MariaDB. On standard SSD (Contabo), average TTFB climbed from 180ms to 520ms as all 15 sites loaded simultaneously. On Hostinger's NVMe, the same test: 165ms to 240ms. The NVMe's 65,000+ IOPS means MariaDB reads do not queue behind each other when 15 sites all need database results at the same time.

The tradeoff is clear: 4GB RAM and 50GB NVMe versus Contabo's 8GB and 200GB SSD at nearly the same price. You get half the sites but each site is measurably faster. For client-facing WordPress sites where Core Web Vitals scores directly impact Google rankings, Hostinger's NVMe advantage is not theoretical — it shows up in Lighthouse scores and Search Console data.

The 1 vCPU entry plan is the constraint for busy multi-site setups. When multiple sites receive concurrent traffic, CPU becomes the bottleneck. The $10.49/mo plan (2 vCPU / 8GB / 100GB NVMe) resolves this and is my recommendation for anyone planning to host more than 10 sites on Hostinger. That plan gives you the speed of NVMe with enough RAM and CPU for 20+ sites comfortably.

Hostinger provides weekly automatic backups on all VPS plans — a Layer 3 backup you get for free instead of managing snapshots manually. For the multi-site use case, this is a legitimate operational advantage.

Best for: SEO professionals and web developers hosting 10-20 performance-critical client sites where TTFB and Core Web Vitals scores matter more than maximizing site count per dollar.

#3 RackNerd — Cheaper Than What You Are Paying for One Shared Hosting Account

Run the numbers on what you are currently spending. If you have 5 personal sites on separate shared hosting at $5-10/month each, that is $25-50/month for hosting you cannot configure, cannot optimize, and cannot even SSH into. RackNerd at $2.49/month gives you full root access, 1.5GB RAM, and 30GB NVMe. Five WordPress sites with pm = ondemand and pm.max_children = 2 per pool. Total PHP-FPM overhead: under 350MB. It works.

The constraints are real. 1.5GB RAM means MariaDB gets a 256MB buffer pool, system overhead takes 200MB, and you have roughly 1GB for everything else. Skip Redis on this plan — the RAM is better spent on PHP-FPM workers. Use WP Super Cache or W3 Total Cache to serve most requests from static HTML files, keeping PHP invocations minimal. The cheapest VPS tier requires the most careful optimization, but that optimization effort also teaches you the most about server management.

I set up a RackNerd test server with 8 WordPress sites to find the breaking point. Sites 1-5 performed well (TTFB under 300ms). Sites 6-7 were acceptable (TTFB 400-500ms under concurrent load). Site 8 caused intermittent 502 errors when more than 3 sites had simultaneous traffic. The practical limit on the $2.49 plan is 5-7 sites, depending on how lean you keep them.

RackNerd's support is slower than premium providers (8-12 hour ticket response in my experience) and the SolusVM control panel is basic. If you are comfortable with SSH, Nginx configuration files, and reading error logs, this is not a factor. If you need hand-holding, Hostinger or DigitalOcean are better choices despite costing more.

Best for: Developers consolidating personal blogs, portfolio sites, and side projects. Also excellent as a staging environment that mirrors a multi-site production setup at near-zero cost.

#4 Vultr — This Is the VPS I Actually Use for My 14 Sites

Full disclosure: my 14-site server runs on Vultr's $12/month plan (2 vCPU, 4GB RAM, 80GB NVMe, New York DC). I chose Vultr for three reasons that are specific to multi-site hosting rather than general VPS quality.

Reason 1: Snapshots. Vultr's snapshot feature captures a full disk image of the VPS. Before making any server-wide change (Nginx config overhaul, PHP version upgrade, MariaDB migration), I take a snapshot. If the change breaks something, I restore the entire server to the pre-change state in 3-5 minutes. When you are managing 14 sites, "something might break" is not hypothetical — it is a weekly occurrence. Snapshots are free for up to 1 snapshot per VPS.

Reason 2: 9 US data centers. My 14 sites primarily serve East Coast audiences, so the New York DC is ideal. If I took on West Coast clients, I would spin up a second Vultr VPS in Los Angeles and distribute sites by geography. No other provider at this price tier gives you 9 US locations to choose from.

Reason 3: API-driven infrastructure. I have a deployment script that uses Vultr's API to provision a new VPS, run the initial setup playbook (Ansible), configure Nginx server blocks, create PHP-FPM pools, set up MariaDB databases, and install SSL — all automated. When I need to migrate to a larger plan or different DC, the script handles everything. For someone managing 14 sites, automation is not a luxury; it is how you avoid configuration drift between manual changes.

Vultr's $5/month entry plan (1 vCPU, 1GB RAM) is too small for multi-site hosting — MySQL alone needs 500MB. Start at $12/month (2 vCPU, 4GB) for 10-25 sites, or $24/month (2 vCPU, 4GB, 128GB NVMe, additional bandwidth) if your sites have media-heavy content. The $100 free credit lets you test the multi-site setup extensively before committing.

Best for: Developers and agencies who want snapshot-based safety nets, geographic flexibility across US regions, and API automation for managing multi-site infrastructure. This is the "infrastructure engineer's choice" for multi-site hosting.

#5 DigitalOcean — Where You Learn to Do This Before You Do It in Production

If this article is the first time you have considered hosting multiple sites on a single VPS, start with DigitalOcean. Not because the hardware is better — it is comparable to Vultr — but because their tutorial library will walk you through every step of the setup with copy-pasteable commands and explanations of what each command does.

Specific DigitalOcean tutorials that directly apply to multi-site VPS setup:

• "How to Set Up Nginx Server Blocks (Virtual Hosts) on Ubuntu" — the definitive Nginx vhost configuration guide
• "How to Install Linux, Nginx, MySQL, PHP (LEMP stack) on Ubuntu" — the complete base stack
• "How to Secure Nginx with Let's Encrypt on Ubuntu" — SSL for each domain
• "How to Create a Self-Signed SSL Certificate for Nginx" — for staging environments

I used DigitalOcean to learn this entire stack in 2019. Their documentation is more reliable than random blog posts because it is updated for each Ubuntu LTS release, tested by their editorial team, and includes troubleshooting sections for common errors. The $200 free credit over 60 days gives you enough runway to build, break, and rebuild a multi-site VPS multiple times while learning.

The 1GB entry plan is a learning environment, not a production multi-site server. For actual multi-site hosting, the $12/month (2 vCPU, 2GB) or $24/month (2 vCPU, 4GB) tiers are where DigitalOcean becomes practical. The 99.99% uptime SLA — the best on this list — matters when clients depend on those sites being accessible.

DigitalOcean also offers Managed Databases (MySQL starting at $15/month) that offload database management to a separate hosted instance. For multi-site setups where the database is your bottleneck and you are willing to pay for the convenience, this lets you scale the web server and database server independently.

Best for: Developers learning Linux VPS administration for the first time. Also suitable for agencies where the 99.99% SLA and managed database option justify the premium over Contabo or RackNerd.

Multi-Site VPS Comparison: The Numbers That Actually Matter

"Tested Sites" = number of WordPress sites with isolated PHP-FPM pools that maintained sub-500ms TTFB under 50 concurrent requests per site. Tested March 2026 with Ubuntu 24.04, Nginx 1.24, PHP 8.3-FPM, MariaDB 11.4.

How I Tested: Breaking Each Provider on Purpose

The testing methodology was deliberately adversarial. I did not test "can this server host 14 sites" — I tested "at what point does this server fall over and how does it fail."

1. Identical stack everywhere: Ubuntu 24.04 LTS, Nginx 1.24, PHP 8.3-FPM with isolated pools (pm = ondemand, pm.max_children = 3), MariaDB 11.4, Redis 7.2 for object caching (where RAM allowed), Certbot for SSL.
2. WordPress sites provisioned with WP-CLI: Each site had the Twenty Twenty-Four theme, WooCommerce (for database query complexity), Contact Form 7, and 500 sample posts with featured images. Not minimal test sites — realistic production-like installs.
3. Load testing with wrk: 50 concurrent connections per site, 60-second test duration, hitting the homepage (cached) and a WooCommerce product page (uncached, database-heavy). I added sites 5 at a time until TTFB exceeded 500ms or 502 errors appeared.
4. OOM monitoring: Watched dmesg | grep -i oom and journalctl -u mariadb for OOM Killer activity. The "tested sites" number in the comparison table is the count where no OOM events occurred during the full 60-second load test.
5. Pricing verified March 2026: All prices are current as of testing. See our benchmarks page for raw performance data on each provider.

Frequently Asked Questions