Zero-Downtime WordPress Deployments: Blue-Green and Sequential Updates on a PaaS Cluster

Every WordPress team has the same unwritten rule: deploy at night, hope the cache warms before the morning traffic, and keep the maintenance-mode plugin ready. On a single server that rule is the only option, because updating files under a live PHP process means errors for whoever hits the site mid-copy. This post walks through how a DevOps engineer removes the rule entirely on a WordPress cluster running on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The scenario is a mid-sized publisher we will call Northline Media: a news site on the WordPress Cluster Kit with two LiteSpeed application servers behind a load balancer, a primary-primary MariaDB cluster, Redis and shared storage. Traffic peaks at lunchtime, which is exactly when the editorial team wants a new front-page layout live.

Why WordPress deployments cause downtime in the first place

A WordPress release is rarely one file. A theme update touches templates, compiled CSS and often a functions file that every request loads. A plugin update can change database schema on first activation. While those files are being copied, PHP serves a mixture of old and new code, and the visible result is a fatal error or a half-styled page for anyone who requests it during the copy. Maintenance mode hides the problem by turning it into a deliberate outage.

On a cluster the copy problem is multiplied by the number of application servers, and a new one appears: the database. If the new theme expects an option that only exists after activation, the first server to finish will behave differently from the others until they all catch up. Zero-downtime deployment is therefore two problems, files and coordination, and the platform gives you tools for both.

Option one: sequential rollout across the application servers

The simplest improvement needs no extra infrastructure. MassiveGRID PaaS treats the two LiteSpeed nodes as one layer, and any intrusive operation on that layer, a restart, a container redeploy, a code deployment from an archive or a Git repository, or even a change to the cloudlet limit, can run sequentially instead of simultaneously. The platform takes the first node out of the load balancer's DNS, applies the change, waits a configurable delay (30 seconds by default, up to five minutes), then moves to the next node.

For Northline the DevOps engineer connects the theme repository to the application-server layer through the Deployment Manager and enables auto-deploy with a one-minute check interval. When the front-end developer merges to the release branch, the platform pulls the change and applies it to node one while node two keeps serving every request. HTTP is stateless, so the balancer simply routes to the healthy node. Sixty seconds later node two updates. The site never returns an error.

Two details matter. First, the WordPress cluster stores uploads on shared storage, so a deployment only replaces code and never touches media. Second, the layer runs in stateful scaling mode, which means a node added later by auto-scaling is cloned from the master container and already carries the deployed code. A stateless layer would be created from the base image and would need the deployment repeated, which is why the WordPress kits default to stateful.

Option two: blue-green with Traffic Distributor

Sequential rollout is enough for a theme tweak. It is not enough when a release includes a plugin that migrates the database, because both application servers share one MariaDB cluster and the migration runs the moment the first node activates the plugin. For those releases Northline uses a blue-green pattern, and the platform makes it a five-minute exercise rather than a project.

Step one is cloning the environment. From the dashboard, Clone Environment produces a complete copy of the WordPress cluster, load balancer, application servers, database and storage, in a few minutes. The clone is the green environment. The engineer points it at a copy of the production database (the cluster's own backup add-on can restore last night's dump into the clone) and deploys the release there. QA tests the green site on its own URL while blue keeps serving the public.

Step two is the Traffic Distributor, a free marketplace add-on that installs a pair of NGINX nodes in front of two backends with a weight slider between them. Northline runs it permanently in front of blue and green, with a public IP as the entry point and the site's domain pointing at it. For a normal day the ratio is 100 to 0. On release day the engineer moves the slider to 90 to 10, watches the error rate on the green cluster for ten minutes, then to 50 to 50, then to 0 to 100. If anything looks wrong at any step, the slider goes back and no user notices. When green is fully live, blue is redeployed with the same release and becomes next month's green.

The distributor's health check does the rest. By default it polls both backends every three seconds and drops one from rotation after three failed checks, re-adding it after three successes. Even if the green environment crashed under load, traffic would fall back to blue within about ten seconds without anyone touching the slider.

What the release day looks like in practice

The cost of the green environment is the interesting part. Because billing is hourly and per cloudlet (128 MiB of RAM plus 400 MHz of CPU), the clone costs money only while it runs. Northline stops the green environment outside release windows, and a stopped environment is charged for disk only. Running it for the six hours above at the same size as production adds a fraction of a day's hosting to the month, which is a far cheaper insurance policy than a maintenance page at lunchtime.

Handling the database during blue-green

The honest complication in any WordPress blue-green setup is state. Comments, form submissions and WooCommerce orders written to green during the 50/50 window do not exist in blue's database. Northline handles this in one of two ways depending on the release.

• Shared database, no schema change. For the majority of releases, both environments point at the same MariaDB cluster. The ProxySQL entry point, proxy.<environment>.<platform domain>, accepts connections from the clone over the internal network, which is free of traffic charges. Blue-green then only separates code, and there is nothing to reconcile.
• Separate database, schema change. When a plugin migrates the schema, green gets its own database copy, the cut-over runs fast (90/10 for a few minutes, then 0/100), and the engineer replays anything written to blue in that short window using the backup add-on's dump and a targeted import. The window is minutes rather than hours precisely because the switch is a slider, not a DNS change waiting on TTLs.

The platform's Database Backup/Restore add-on is what makes the second pattern safe: a manual Backup Now before the cut-over gives a known restore point on a separate storage node.

Why this is hard to reproduce on a VPS

None of the individual techniques above is exotic. Symlink-swapped releases, weighted proxies and rolling restarts all exist on a plain Linux server. What changes on MassiveGRID PaaS is that they arrive configured and wired to the topology. Sequential redeploy knows which nodes are in the load balancer. Cloning copies the whole cluster including its database replication. The Traffic Distributor's health check and routing modes are set from a form. And because every node runs as an isolated container on a different physical host with live migration in the background, a release rollout never competes with the platform's own maintenance for the same server.

The result for Northline is cultural as much as technical. Releases moved from 23:00 on Thursdays to whenever editorial wants them, because a release that can be reversed with a slider is not a risk worth scheduling around.

Frequently Asked Questions

Does zero-downtime deployment work with the WordPress Standalone Kit too?

Partly. The standalone kit runs one application server, so sequential rollout across nodes does not apply, but the PHP application servers on MassiveGRID PaaS support atomic zero-downtime deployment for the ROOT context: a new release is unpacked into a timestamped directory and a symlink switches when it is complete, so requests never see a half-copied tree. Blue-green with Traffic Distributor works for standalone environments exactly as described here.

How long does cloning a WordPress cluster take?

Typically a few minutes, depending on the amount of data in the containers. Application servers are copied from the master container, and a brief freeze on the source nodes can occur while memory state is migrated. Cloning an environment with a Galera database cluster may cause a short pause while the clone and original agree on data consistency, so schedule clones outside peak minutes.

Can I automate the traffic ratio changes?

Yes. The Traffic Distributor is configured through the platform's marketplace add-on interface, and every add-on action is available through the platform API and CLI. A pipeline can move the ratio in steps, check an error-rate metric between steps, and roll back automatically if a threshold is crossed.