Running a WordPress Fleet

Running one WordPress site teaches you WordPress. Running several at once teaches you something different: how to treat sites as a system instead of a menagerie of pets you hand-feed. That shift – from “fix this site” to “operate this fleet” – is a capability of its own, and most of what I know about it I learned by breaking things in production and having to find out why.

I think in three layers, always. Every one of my sites is a stack: an edge (Cloudflare – WAF, caching, DNS), an origin (Cloudways-hosted, with Imunify360 sitting in front of the server), and an app (WordPress itself, plus WooCommerce, plugins, the PHP runtime). The single most useful habit I have is refusing to guess which layer a problem lives in. An incident that looks like a plugin bug is often an edge rule; a “slow site” is often the origin being hammered below the edge’s line of sight. Name the layer first, and the fix usually names itself – which is problem deduction pointed at infrastructure.

The incident that proves the point. One of my commerce sites pinned at 100% CPU and went down. The obvious suspect was the feature I’d deployed that week – a chatbot – and everyone’s instinct, including the reflex to roll back, pointed there. It was wrong. The real cause was that scrapers had found the origin IP directly and were hammering Cloudways while completely bypassing Cloudflare – so every edge rule, every rate limit, every bit of caching I’d tuned was doing nothing, because the traffic never touched the edge. The fix wasn’t a rollback; it was locking the origin to accept only Cloudflare’s IP ranges at the server level, and hardening that with authenticated origin pulls. If I’d “fixed” the thing that got blamed, the site would still have been down and I’d have learned the wrong lesson. State the outcome, find the layer, then act.

WAF rules are a scalpel, not a hammer. The Cloudflare layer is where I’ve made – and caught – my most instructive mistakes, because a security rule is a loaded gun pointed at your own users. Block Woo cart action parameters too broadly and you break real shoppers mid-checkout; the right move is to gate on threat score, not to blanket-ban the URL. Write an admin allow rule that only covers admin-ajax.php and you’ll watch plugin saves silently 403 because half of modern WordPress talks over the REST API at /wp-json/* instead – so the rule has to cover both. Precision here isn’t fussiness; imprecision breaks either your customers or yourself, and both are outages.

Fleet discipline is mostly about blast radius and propagation. Two things separate a fleet from a pile of sites. First, containment: every instance holds its own secrets – its own API keys, its own credentials – so a leak or a rotation is scoped to one site, not the whole set, and I have a fan-out tool to rotate across the fleet without hand-editing each one. Second, propagation: because the sites share one engine (the SIE mother/child model), a fix I make once can ripple everywhere – which is leverage and danger in the same mechanism, so changes get staged and canaried on one site before they reach the rest.

What I’ll own honestly. This is a small fleet – a handful of production sites, deliberately heterogeneous (most on Cloudways, one kept on cPanel because a billing system needs it), not a hundred-site hosting operation. And I’m a pragmatic operator, not a career sysadmin: I know my three layers cold because I’ve been burned at each of them, but I lean on managed hosting and managed edge precisely so I don’t have to run bare metal. The skill isn’t encyclopedic infrastructure knowledge – it’s knowing which layer just failed, containing the damage to one site, and never applying a fix to a fleet that I haven’t proven on one.