Multi-Region WordPress Standalone on PaaS: Two-Region Redundancy for a Site That Does Not Need a Cluster in Every Location

Geographic redundancy used to be reserved for sites large enough to justify a cluster in every location. The Multi-Region WordPress Standalone package removes that threshold: two single WordPress nodes in two regions, connected as one synchronised solution, for a site whose traffic fits comfortably on one server but whose owner cannot accept a data centre outage. This post follows a small publisher adopting it on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The publisher is a trade magazine we will call Kilnworks Journal, about 30,000 monthly visitors, a WordPress site with a paywalled archive, and an editor who lost a week of sleep the last time its host had an outage. The Multi-Region WordPress Standalone package installs a LiteSpeed-powered WordPress instance in each of two regions and keeps them synchronised, with the option of Let's Encrypt and LiteSpeed's brute-force protection and web application firewall at install.

What the package installs

Two regions are selected at install. In each, the package creates a WordPress Standalone environment: LiteSpeed web server (or NGINX if you decline the option) with PHP and MariaDB on one node, with its own platform subdomain. The two environments are then interconnected: MariaDB replication carries database changes from the first environment, the primary, to the second, the replica, and file synchronisation mirrors media uploads and code changes between them. The install options include Let's Encrypt with auto-renewal for the custom domain and LiteSpeed's brute-force attack protection and web application firewall. The editor received both admin URLs and credentials by email and assigned the magazine's domain to the primary.

Standalone versus cluster, by the numbers

Kilnworks sits squarely in the first column. Its whole traffic fits on one LiteSpeed node with room to spare; what it wants is the second column's survival property at the first column's price.

Publish in one place

The package's guidance is to publish in one region and let replication carry the changes, and Kilnworks's editors do exactly that: the admin URL they use is the primary's. Writing simultaneously in both regions is technically possible but invites conflicts, so the replica's admin is left alone in normal operation. Replication runs over the inter-region network; a post published in London appears in Frankfurt's database within a second or so, and its images arrive by file synchronisation shortly after. The editor tested it by publishing on the primary and reloading the replica's subdomain.

Making it geo-distributed, or just redundant

The package's documentation describes two ways to use the pair. The simple one is redundancy: the domain points at the primary, the replica is a warm standby, and if the primary's region is lost the editor changes the DNS record to the replica's address and promotes its database to accept writes. The fuller one is geo-distribution: attach public IPs to both environments and configure DNS load balancing so visitors resolve to the nearer region, with the replica serving reads and the primary taking the editorial writes. Kilnworks chose redundancy first, because its readers are mostly in one country, and wrote down the geo-distribution step for when that changes. The failover runbook is one DNS change and one command on the replica, rehearsed once on the trial and again each quarter.

What the platform adds to the two nodes

Each node is a container on its own physical host in its own data centre, scaling vertically in cloudlets (128 MiB of RAM plus 400 MHz of CPU) by the hour as the magazine's traffic moves, with the platform's live migration and container restoration underneath. The WordPress Backup/Restore add-on archives files and database nightly from the primary to a Backup Storage node; the replica is redundancy, not a backup, because a bad plugin update replicates too. LiteSpeed's cache makes one node go a long way, and the two environments are cloned before any major plugin or WordPress update, which is how the editor found a paywall plugin that broke on a PHP upgrade before readers did.

Cost

The editor also gained something the old host never offered: a permanent second copy of the live site to look at. When a reader reports a broken page, the replica's subdomain shows whether the problem is the content, which replicated, or the primary node, which did not. It has settled two support arguments in the first quarter.

Two LiteSpeed nodes averaging about 8 cloudlets each across the day, roughly 16 cloudlets an hour in total, about $39 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus two small disks and, if geo-distribution is enabled, two public IPs. The Multi-Region Cluster package for the same site would have been several times that for capacity the magazine has no use for. The editor's summary: the site now survives the building, and costs about what the old single-server host did.

Frequently Asked Questions

Can I add a third region later?

Yes. Environments can be cloned to another region and the replication extended to the new node, which MassiveGRID's support can assist with. For three or more full regions from the start, the Multi-Region WordPress Cluster package is the purpose-built option.

Is failover automatic?

With DNS load balancing and health checks at your DNS provider, visitors are routed away from a failed region automatically for reads. Promoting the replica's database to accept writes is a deliberate step, which keeps a network blip from producing two writable copies. Rehearse it on the trial.

Why LiteSpeed rather than NGINX?

LiteSpeed's server-level cache and its WordPress integration let a single node serve far more traffic than a plain PHP stack, which is the point of a standalone-per-region design. NGINX is available as the install option if you prefer it.