Clustered hosting runs one website across several servers instead of one. A load balancer spreads requests between them, so a traffic spike gets absorbed rather than queued, and a failed server takes itself out of rotation instead of taking your site down.
That’s straightforward in principle. WordPress makes it harder in practice — it was built assuming one server with one filesystem, and clustering it means solving four specific problems the marketing pages rarely mention. This guide covers the architecture, those four problems, what a cluster actually costs, and how to choose between building one and buying one.
Don’t want to build the cluster yourself? ConvesioHost gives every WordPress site a containerized, auto-scaling cluster out of the box — with a 99.999% uptime guarantee and automatic failover to a second data center. See plans and pricing →
What Clustered Hosting Is, Briefly
In a single-server setup, one machine handles everything: the web server, PHP, the database, and your media files. It’s simple, and it has one obvious failure mode — when that machine is overwhelmed or goes down, so does your site.
Clustered hosting distributes that work across multiple interconnected servers, with redundant copies of each component. No single machine is a single point of failure, and capacity becomes something you add rather than something you’re stuck with.
For a plain-English breakdown of the concept, see What Is Clustered Hosting? Explained. The rest of this guide assumes you’ve got the basics and focuses on running WordPress on a cluster specifically.
The Anatomy of a WordPress Cluster
A production WordPress cluster has five moving parts. Understanding what each one does is what lets you ask a provider useful questions instead of taking their word for it.
The load balancer. The public entry point. It receives every request and routes it to whichever application node has capacity, using health checks to skip any node that has stopped responding. It also usually terminates SSL, so your application nodes don’t spend CPU on encryption.
The application nodes. Two or more servers each running a web server, PHP, and an identical copy of your WordPress installation. These are the units you add when you need more capacity. Because any node can serve any request, they must all behave identically — which is exactly where WordPress gets awkward.
The database layer. Usually a separate server, or a primary with one or more read replicas. Splitting the database off the application nodes is what allows you to scale the two independently: a traffic spike on a cached marketing page needs more PHP, while a heavy WooCommerce checkout period needs more database.
Shared storage. A single storage layer that every application node mounts, so an image uploaded through the WordPress admin is visible to all of them immediately.
The caching layers. Typically three: an edge or page cache holding rendered HTML, a CDN serving static assets from locations near the visitor, and an object cache holding database query results in memory.
What Happens When Someone Visits Your Site
- The request hits the load balancer.
- If the page is already in the edge cache, it’s returned immediately — no PHP, no database, single-digit milliseconds. On a content site this is most requests.
- If not, the load balancer picks a healthy application node based on current load.
- That node runs PHP, checks the object cache, queries the database for anything not cached, and renders the page.
- The rendered page goes back to the visitor and, if cacheable, into the edge cache for the next person.
If a node fails mid-way, the load balancer’s health check marks it out of rotation and the next request goes elsewhere. Visitors don’t see it happen. That’s failover, and it’s the main reason clustering exists.
The Four Problems WordPress Creates on a Cluster
WordPress assumes one server. Spread it across several and four assumptions break. Any provider worth paying has an answer to all four — asking about them is the fastest way to separate real clustered hosting from a marketing label on a single VPS.
1. Uploads and the shared filesystem. When you upload an image, WordPress writes it to wp-content/uploads on whichever node handled that request. Without shared storage, the other nodes have no idea it exists, and the image 404s for roughly half your visitors. The same applies to plugin installs, theme edits, and anything else that writes to disk. Solutions are shared network storage, object storage such as S3 behind a plugin, or real-time file replication between nodes. Ask which one is in use — “we sync the files” is not a specific enough answer, because sync delay is exactly the failure window.
2. Sessions and carts. This is the one that bites WooCommerce sites. If node A holds a visitor’s session in local PHP storage and their next request lands on node B, their cart appears empty. There are two fixes: sticky sessions, where the load balancer pins each visitor to one node, or — better — a shared session store so any node can serve any visitor. Sticky sessions are the weaker option because they undo some of your load balancing and lose the cart anyway if that node dies. If you run a store, ask this question first.
3. Database writes and replication lag. Read replicas scale reads beautifully, but WordPress writes to a single primary, so writes don’t scale the same way. Worse, a replica is always slightly behind. Publish a post, get routed to a lagging replica on the next request, and the post appears to have vanished. Any serious setup routes reads that must be current — the admin, checkout, logged-in sessions — to the primary. High write volume, meaning busy stores, membership sites, and anything with heavy commenting, is the real constraint on how far a WordPress cluster scales.
4. Cache invalidation across nodes. Update a page and the cached copy has to be cleared everywhere: every application node’s object cache, the page cache, and the CDN. Miss one and different visitors see different versions of your site — a class of bug that is genuinely painful to diagnose, because it only reproduces on some requests. Clustered environments need cache purging that fans out across the whole cluster, not per-node clearing.
The Fifth Problem: WP-Cron
WordPress runs scheduled tasks on page loads. On a cluster, every node runs its own scheduler, so a task meant to run once can run several times — duplicate emails, duplicate orders processed, duplicate imports. The fix is to disable wp-cron.php and drive scheduled tasks from a single system cron. Most managed clustered hosts do this by default; if you’re building your own, it’s on you.
Build It or Buy It: Three Approaches Compared
| Single server / VPS | Self-built cluster | Managed WordPress cluster | |
|---|---|---|---|
| Typical monthly cost | $20–$100 | $200–$800 infra, plus engineering time | $50–$600+ all-in |
| Who solves the four problems | N/A — one server | You do, and you own every regression | The provider, before you arrive |
| Failover | None — reboot and hope | Whatever you configure | Automatic |
| Scaling a spike | Resize and reboot | Minutes to hours, if pre-automated | Automatic |
| Ongoing ops burden | Low | High — patching, monitoring, replication health, on-call | None |
| Best for | Brochure sites, blogs | Teams with a sysadmin and unusual requirements | Business-critical sites and stores without a sysadmin |
The honest summary: building your own cluster makes sense when you have genuinely unusual infrastructure requirements and someone whose job is to maintain it. For most WordPress sites, the engineering time costs more than the hosting, and the failure modes above are ones you’d rather discover in someone else’s documentation than in your own production logs.
What Clustered Hosting Actually Costs
Clustering costs more than single-server hosting, for the obvious reason: you’re paying for redundancy, and redundancy means paying for capacity you hope never to need. What surprises people is where the rest of the money goes.
The infrastructure is the visible part. The invisible parts are the ones that decide whether building your own is really cheaper: patching and updates across every node, monitoring that has to watch replication health rather than just uptime, someone available when a node fails at 2am, and the engineering hours to solve the uploads, sessions, replication and cache problems above — once to build, and again every time something changes.
Against that, weigh what downtime costs you. For a store doing meaningful revenue, an hour offline during a sale usually exceeds a year of the difference between shared hosting and a managed cluster. If you’re running a personal blog, it doesn’t, and single-server hosting is the correct answer — this guide shouldn’t talk you into infrastructure you don’t need.
How to Choose a Clustered Hosting Provider
Beyond reputation and support quality, ask these. The answers separate real clustered infrastructure from a marketing label:
- How do you handle uploads across nodes? You want shared or object storage, not periodic sync.
- How are sessions and carts kept consistent? Shared session store beats sticky sessions.
- Is the database replicated, and how do you handle replica lag for logged-in users?
- Does cache purging fan out across the whole cluster?
- Is scaling automatic, or do I request it? And if automatic — how quickly, and is there a ceiling?
- Is WP-Cron handled at system level?
- Where does failover go? Another node in the same data center is much weaker protection than another data center.
- What’s the backup cadence, and where are backups stored? Backups on the same cluster they’re protecting aren’t backups.
- Is migration included?
Reading the SLA Properly
An SLA is a formal commitment on uptime, response times, and what you’re owed when they’re missed. Two things to check before you’re impressed by a number. First, what counts as downtime — some SLAs exclude scheduled maintenance, partial degradation, and anything traced to your own plugins, which can quietly exclude most of what you’d actually experience as an outage. Second, what the remedy is: most uptime guarantees pay out in service credits, not compensation for lost sales, and they usually require you to file a claim within a set window.
The practical difference between 99.9% and 99.999% is worth knowing: 99.9% permits about 8.8 hours of downtime a year, while 99.999% permits about 5 minutes.
Moving an Existing WordPress Site Onto a Cluster
Migration is where clustered setups tend to go wrong, because problems that don’t exist on a single server appear the moment traffic is split across nodes.
- Audit what writes to disk. Caching plugins, backup plugins, image optimizers, and file-based logging all write locally and all misbehave on a cluster. Identify them before you move, not after.
- Move media to shared or object storage first, while you’re still on one server and mistakes are cheap.
- Check session handling if you run a store, a membership site, or anything with logged-in users.
- Replicate first, cut over second. Run the cluster alongside the live site and test it under real load before pointing DNS.
- Lower your DNS TTL a day ahead so the cutover propagates in minutes and rollback stays cheap.
- Test with caching on. Nearly every “it worked in staging” incident comes from staging having caching disabled.
- Watch for a week, specifically for the four failure modes above rather than just uptime.
Providers offering managed migrations do most of this for you, which is worth more than it sounds — the hard part isn’t copying files, it’s knowing which plugins will break.
Clustered WordPress Hosting Without the Cluster Management
Convesio was built specifically to make clustered WordPress the default rather than a project. Every site runs on a containerized cluster from day one, with the four problems above already solved at platform level:
- Cross-data-centre failover. Every site has a redundant copy in a second data centre. If the primary fails, requests move automatically; during a prolonged outage the secondary is promoted without anyone touching anything.
- Automatic scaling. Sites scale PHP workers in real time and burst during traffic spikes, without reprovisioning or migration.
- Three caching layers as standard — edge caching for rendered pages, a built-in CDN for static assets, and Memcached for objects and transients.
- Backups that live elsewhere. Daily file backups plus database backups every two hours, taken on a replica so production performance isn’t affected, retained for two weeks with monthly snapshots kept for a year.
- Automatic rollback on fatal errors. The platform watches for fatal errors and reverts to the last working state rather than leaving a white screen up.
- A 99.999% uptime guarantee, unlimited visitors, and white-glove migration included on every plan.
Plans start at $50/month, with dedicated CPU added as you grow. Compare plans and pricing →
Ready to stop managing servers? ConvesioHost runs your WordPress site on an auto-scaling cluster with automatic failover, three caching layers, and migration handled for you. See plans and pricing → or see how the cluster works →