Revisiting the Cloud VPS model: weak points and a VPS consolidation plan

This is the final article in the Cloud VPS series. Having walked through each tier, balancer, minion and database, along with the automation and defense layers, it is time for an honest look back: what this model does well, where it tends to be weak, and whether, as the number of Cloud VPS instances grows over time, VPS consolidation makes sense. This article sums up the lessons of the series, lists the typical single points of failure of the three-tier model, explains how to draw up a safe VPS consolidation plan, and points to the road ahead.

1. Looking back at the Cloud VPS model across the series

The three-tier model in Cloud VPS architecture: Balancer, Minion and Database tiers for hundreds of PHP sites has a very stable skeleton. What changes over time are the layers built on top of it:

All of it uses only familiar tools: nginx, PHP-FPM, MySQL, supervisor, systemd. That is both a strength and the foundation for thinking about VPS consolidation.

2. What the model does well

• A small attack surface: only the balancers have public IPs. Minions and databases only listen on the private network.
• Per-site isolation that clearly works: splitting a dedicated PHP-FPM pool per site made the shared pool's reached pm.max_children errors disappear. Moving Octane to systemd means a site hit by OOM only restarts itself, within a few seconds.
• Blocking early at the balancer: the security snippet, WAF and rate limiting return 403, 429 or 444 right at the balancer for a significant share of junk requests, without spending a single PHP worker.
• Automation that is good enough and easy to understand: creating sites, deploying with rollback, backups and SSL renewal are all pipelines; for any incident, following the three tiers leads you to what broke.

3. Weak point one: no HA, each site lives on exactly one machine

If every upstream block on the balancer has only one server, declaring least_conn is meaningless. Two typical kinds of incident, which are also why every VPS consolidation plan has to account for HA:

• A slowly dying minion: a minion degrades gradually, the balancer's error log fills with upstream timed out pointing at the same machine, and the only fix is to move the sites off by hand.
• The whole upstream group dies at once: even when an upstream has several servers, if they are all marked down for a common reason (a slow database, a failed deployment), nginx returns no live upstreams for every request.

The balancer itself is also a single point of failure: when one balancer fails, every site behind it goes down with it, and without a floating IP there is no way to fail over to another machine. The classic solution is a pair of balancers running keepalived (VRRP): a floating IP that moves between the two machines when one of them dies.

4. Weak point two: data and disk space

This is also the hardest tier for VPS consolidation. To save resources on small VPS instances, many multi-tenant MySQL setups turn off the binlog (skip-log-bin): no binlog means no replica and no point-in-time recovery. Data safety then rests entirely on the nightly mysqldump. If the database machine's disk fails in the afternoon, the data written between the previous night's dump and that moment is lost.

Disk space is the second time bomb. Copies of databases made for testing, logs that are never rotated, and backups forgotten on the machine tend to fill the disk. Alerts only help when there is a cleanup procedure to go with them; otherwise full disks will block the path to VPS consolidation.

# which databases take the most space: candidates to clean up before VPS consolidation
mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS mb
          FROM information_schema.tables GROUP BY table_schema ORDER BY mb DESC LIMIT 10;"

5. Weak point three: inconsistent configuration across machines

Each improvement is usually made on a few machines first. Without an audit step, many improvements stop there: this balancer has the WAF, that one does not; this machine has fail2ban, that one does not; an old minion still uses the shared PHP-FPM pool. A checklist of "which component is on which machine" should be generated automatically on a schedule rather than kept in someone's memory.

Another symptom of the same disease: pipelines and alerts are not cleaned up along with the machines. A machine is decommissioned but the cache-clearing job still SSHes into it, the SSL renewal job still runs and turns red because it cannot resolve the hostname, and Grafana still has alert rules for a machine that no longer exists. The root of all this is the lack of a single place that describes the desired state of the whole system, such as Ansible or an infrastructure-as-code tool, so each machine gradually becomes a "snowflake". VPS consolidation that does not fix this just packs many snowflakes onto fewer machines.

6. How to draw up a VPS consolidation plan

Once the applications have been optimized (N+1 queries fixed, caching enabled), monitoring usually shows many machines sitting idle most of the time, and many small sites spread thinly across too many Cloud VPS instances. VPS consolidation is the natural next step, but a VPS consolidation plan should follow these principles:

1. Measure before VPS consolidation. Take each machine's CPU, RAM and disk usage at peak hours from Prometheus, not the daily average.
2. Leave clusters rented by customers as dedicated infrastructure alone. Each such cluster keeps its own balancer, minions and database.
3. Clean up first, consolidate later. Review websites whose contracts have ended, old test domains and sites that have moved away. Back them up to object storage, then remove them.
4. Isolate first, then do the VPS consolidation. Every site gets its own FPM pool, and every Octane site its own systemd unit with MemoryMax, before they are packed onto shared machines.
5. Spend the savings from VPS consolidation on safety: HA for the balancers and replicas for the databases.

7. Three things to know when carrying out VPS consolidation

• VPS consolidation increases the blast radius. With ten sites on one machine, one failing site can drag the other nine down. That is why isolation has to come first, and why the articles on PHP-FPM pools and on running Octane with systemd are prerequisites.
• Disk and RAM limit the pace of VPS consolidation. A database machine with a nearly full disk cannot take more databases. An Octane minion can still run out of RAM as a whole even though every site has its own limit, if the sum of the limits exceeds the real RAM.
• Decommissioning a machine means removing its "shadow" too. Every machine removed during VPS consolidation leaves behind pipelines, alert rules and internal DNS records pointing at it. Before removing it, grep for the hostname in the nginx, DNS, Prometheus and Jenkins configurations.

8. Lessons from the Cloud VPS series

1. Simplicity is a real advantage. A small team can run hundreds of sites on many small Cloud VPS instances because everything is visible and fixable over SSH.
2. Measure first, fix later. The most effective improvements (dedicated pools, rate limiting by User-Agent) all started from counting log lines, not from gut feeling.
3. Isolation is cheaper than scaling out. Splitting pools and services costs less than adding machines, solves exactly the "one site drags the whole machine down" problem, and is the precondition for safe VPS consolidation.
4. Missing HA and missing binlogs are the two biggest debts. No other defense layer makes up for the fact that one dead machine means a dead site, or one failed disk means a day of lost data. The minimum step for databases is to enable binlog and set up replicas following the MySQL replication documentation for the important machines.
5. Configuration needs a single source of truth. Shell scripts in Jenkins make things fast, but they do not stop machines from gradually drifting apart.

9. The road ahead: Kubernetes

Alongside the Cloud VPS model, part of our websites runs on Kubernetes. Kubernetes addresses exactly the weak points in sections 3 and 5: several pods per site, dead pods replaced automatically, rolling deployments, and resource limits declared in charts and applied consistently. In exchange, it is more complex, and it does not cure leaky code: a pod that exceeds its limit still gets OOMKilled.

This is not a matter of choosing one and dropping the other. VPS consolidation and a gradual move to Kubernetes can run in parallel. Cloud VPS still suits small sites, legacy sites that are hard to containerize, and customers who need a dedicated cluster. Kubernetes suits products that need to scale and deploy frequently. That story, from dockerizing Laravel and shared Helm charts to CI/CD and incidents on the cluster, is told in the Kubernetes & CI/CD at Sudo series on Sudo's engineering blog.

Series wrap-up

Thank you for following the Cloud VPS series. The Balancer – Minion – Database model is not perfect, but it runs hundreds of websites at low cost, and every incident has left behind a concrete lesson. If you run a similar system and are thinking about VPS consolidation, remember the order: measure, clean up, isolate, and only then consolidate.

The next chapter, when we moved Website AI onto containers and Kubernetes, is in the Kubernetes & CI/CD series; incidents and operational lessons are collected in the Production Operations series.