We run 5 WordPress sites on a single Google Compute Engine instance. Same VM, different databases, different domains, zero conflict. The architecture saves us $400/month in infrastructure costs and gives us 99.5% uptime. Here’s how it works.
Why Single-VM Clustering?
Traditional WordPress hosting: 5 sites = 5 separate instances = $5-10/month per instance = $25-50/month minimum.
Our model: 5 sites = 1 instance = $30-40/month total.
Beyond cost, a single well-configured VM gives you:
– Unified monitoring (one place to see all sites)
– Shared caching layer (better performance)
– Easier backup strategy
– Simpler security patching
– Better debugging when something breaks
The Architecture
Single Compute Engine instance (n2-standard-2, 2vCPUs, 8GB RAM) runs:
– Nginx (reverse proxy + web server)
– MySQL (one database server, multiple databases)
– Redis (unified cache for all sites)
– PHP-FPM (FastCGI process manager, pooled across sites)
– Cloud Logging (centralized log aggregation)
How Nginx Routes Requests
All 5 domains point to the same IP (the VM’s static IP). Nginx reads the request hostname and routes to the appropriate WordPress installation:
“`
server {
listen 80;
server_name site1.com www.site1.com;
root /var/www/site1;
include /etc/nginx/wordpress.conf;
}
server {
listen 80;
server_name site2.com www.site2.com;
root /var/www/site2;
include /etc/nginx/wordpress.conf;
}
“`
(Repeat for sites 3, 4, 5)
Nginx decides based on the Host header. Request for site1.com goes to /var/www/site1. Request for site2.com goes to /var/www/site2.
Database Isolation
Each site has its own MySQL database. User “site1_user” can only access “site1_db”. User “site2_user” can only access “site2_db”. If one site gets hacked, the attacker only gets access to that site’s database.
Cache Pooling
All 5 WordPress instances share a single Redis cache. When site1 caches a query result, site2 doesn’t accidentally use it (because Redis keys are namespaced: “site1:cache_key”).
Shared caching is actually good: if all sites query the same data (like GCP API results or weather data), the cache hit benefits all of them.
Performance Implications
– TTFB (Time To First Byte): 80-120ms (good)
– Page load: 1.5-2 seconds (excellent for WordPress)
– Concurrent users: 500+ on peak (adequate for these sites)
– Database query time: 5-15ms average
We’ve had 0 issues with performance degradation even under load. The constraint is usually upstream (GCP API rate limits, not server capacity).
Scaling Beyond 5 Sites
At 10 sites on the same VM, performance stays good. At 20+ sites, we’d split into 2 VMs (separate cluster). The architecture scales gracefully.
Monitoring and Uptime
All 5 sites use unified Cloud Logging. Alerts go to Slack if:
– Any site returns 5xx errors
– Database query time exceeds 100ms
– Disk usage exceeds 80%
– CPU exceeds 70% for 5+ minutes
– Memory pressure detected
Uptime has been 99.52% over 6 months. The only downtime was a GCP region issue (not our fault) and one MySQL optimization that took 2 hours.
Backup Strategy
Daily automated backups of:
– All 5 database exports (to Cloud Storage)
– All 5 WordPress directories (to Cloud Storage)
– Full VM snapshots (weekly)
Recovery: if site2 gets corrupted, we restore site2_db from backup. Takes 10 minutes. The other 4 sites are completely unaffected.
Security Isolation
– SSL certificates: individual certs per domain (via Let’s Encrypt automation)
– WAF rules: we use Cloud Armor to rate-limit per domain independently
– Plugin/theme updates: managed per site (no cross-contamination)
The Trade-offs
Advantages:
– Cost efficiency (70% cheaper than separate instances)
– Unified monitoring and management
– Shared infrastructure reliability
– Easier to implement cross-site features (shared cache, unified logging)
Disadvantages:
– One resource constraint affects all sites
– Shared MySQL connection pool (contention under load)
– Harder to scale individual sites independently (if one site gets viral, all sites feel it)
When To Use This Architecture
– Managing 3-10 sites that don’t have extreme traffic
– Sites in related verticals (restoration company + case study sites)
– Budget-conscious operations (startups, agencies)
– Situations where unified monitoring matters (you want to see all sites’ health at once)
When To Split Into Separate VMs
– One site gets >50K monthly visitors (needs dedicated resources)
– Sites have conflicting PHP extension requirements
– You need independent scaling policies
– Security isolation is critical (PCI-DSS, HIPAA, etc.)
The Takeaway
WordPress doesn’t require a VM per site. With proper Nginx configuration, database isolation, and monitoring, you can run 5+ sites on a single instance reliably and cheaply. It’s how small agencies and bootstrapped operations scale without burning money on infrastructure.
Leave a Reply