It's Friday afternoon. A security patch just dropped for a plugin running on 40-something client sites. You open your FTP client, start dragging updated files onto the first server, and quietly hope none of the 40 has a customized version of that plugin, a theme override that depends on the old behavior, or a database change that needs to run in a specific order. One of them does. By the time a client emails my site is down,
you're SSH-less, rollback-less, and reconstructing what changed from memory.
Running one WordPress site this way is survivable. Running a fleet of them is a liability. The problem isn't WordPress — it's that plugin-and-theme updates across dozens of client installs are a release operation, and most agencies are still performing that operation by hand, one FTP drag at a time, with no staging and no way back.
The problem is fleet-scale release operations, not WordPress
A single WordPress deploy is forgiving. You can drag a theme folder over FTP, refresh the page, and fix it live if something breaks. That forgiveness is exactly what doesn't scale. When the same change has to land on 40 sites, the small risks you tolerate on one install multiply into near-certainty across the fleet: the odds that at least one site has a customization, a stale cache, or a migration ordering problem approach 100% as the fleet grows.
Fleet-scale release operations have requirements a manual FTP workflow can't meet:
- Repeatability — the same change applied the same way to every site, not 40 slightly different hand-jobs.
- Staging — a place to see the change render before a client does.
- Ordering — database migrations and file changes that land in the right sequence.
- Rollback — a one-step way back when a deploy goes wrong on site #37.
- Auditability — a record of what changed, when, and who shipped it.
Git-based deployment gives you all five. It's the same discipline you'd bring to a single high-value app, applied uniformly across the fleet. If you've automated deployments for a single client before — the way we walk through in automating WordPress deployments from Git — fleet operations are that pattern, templated and repeated.
Why FTP falls apart at fleet scale
FTP is a file-copy protocol. It has no concept of a release, a build step, an atomic switch, or a rollback — it just overwrites whatever's there with whatever you drag. At single-site scale you paper over those gaps with care and luck. Across a fleet, the gaps become the failure modes:
- Partial deploys. An interrupted FTP transfer leaves a site half-updated — new theme files against old plugin code — and serving that broken state to visitors until you notice.
- No build step. Composer dependencies, compiled assets, and minified CSS/JS all have to be committed to the repo or built by hand, because FTP can't run anything.
- No atomic switch. Files change in place while visitors are mid-request, so someone always catches the site mid-deploy.
- No record. Nothing logs which of the 40 sites got the update and which timed out.
FTP being the wrong tool for production deployments isn't a WordPress-specific claim — it's a general one we make in why FTP is a deployment liability in 2026. At fleet scale, it stops being a nuisance and becomes the thing that takes a client offline.
The four failure modes of multi-site WordPress deployment
1. Updates with nowhere to stage them
Pushing a plugin update straight to production means the client's live site is your test environment. On a fleet, you can't manually smoke-test 40 sites after every patch, so breakage ships silently and you find out from a support ticket. A Git workflow with a staging target per site — or a shared staging pattern — lets the change render somewhere safe first, and lets you promote to production only once it's verified.
2. Database migrations and serialized data
WordPress stores serialized PHP arrays in the database, and serialized strings encode their own byte length. That's why a naive find-and-replace of a domain or path during a migration silently corrupts widget settings, theme options, and plugin config — the replaced string no longer matches its recorded length. Across a fleet, one careless search-replace can quietly break serialized options on every site it touches. Deployments have to treat the database as a first-class, ordered step (WP-CLI's search-replace handles serialization correctly), not an afterthought you run by hand on whichever sites you remember.
3. Override drift
Client sites drift. A client edits a template directly in the admin, a temporary
hotfix gets FTP'd straight to production, a plugin auto-updates itself. Now the live site no longer matches your repo — so your next deploy either clobbers the client's change or fails in a way that's hard to diagnose. Git as the single source of truth turns drift into a visible diff instead of an invisible landmine: the repo is authoritative, and anything not in it is a deviation you can see and reconcile.
4. No rollback path
This is the one that ends Fridays. When an FTP deploy breaks site #37, there's no undo
— you're manually re-uploading the previous version you hopefully still have a copy of. Atomic, release-based deployment keeps prior releases on the server and switches between them with a symlink, so recovering a broken site is one-click rollback, not an archaeology project.
Running a whole agency on the FTP-and-hope workflow doesn't just risk a bad afternoon — it caps how many clients you can safely take on. If fleet reliability is what's holding your roster back, that's a deployment problem worth fixing before it's a growth problem. See how agencies run multi-client delivery on DeployHQ for the operational picture.
A repeatable release pipeline for every client site
The core move is to make each client site a project with the same shape, so a release is the same operation everywhere:
- Git is the source of truth. Every site's theme, plugins (or
composer.json), and config live in a repository. Deploys come from commits, not from your desktop. - Build off-host. Composer install,
npm run build, asset minification — all of it runs on a build pipeline before anything reaches the server, so shared hosts that can't run Composer aren't a blocker and the site never builds mid-request. - Templates make it repeatable. Rather than reconfiguring 40 projects by hand, deployment templates let you define the build-and-deploy config once and reuse it across every client site, so a new site inherits the fleet's proven pipeline instead of a fresh chance to misconfigure.
- Atomic release + database step. The deploy uploads to a fresh release directory, runs the ordered database migration, then switches the live symlink — so visitors only ever see a complete release.
This is the pattern behind the general WordPress theme deployment workflow; fleet operations are that workflow made uniform across every client via templates.
Staged rollout across the fleet
Even with a solid per-site pipeline, don't ship a plugin update to all 40 sites at once. Treat the fleet like a deployment ring:
- Canary first. Push the change to one or two low-risk sites and verify they render and function.
- Then the batch. Roll the remainder once the canaries are clean.
- Watch for the outliers. The sites with heavy customization or unusual plugin stacks are where breakage hides — deploy those consciously, not as part of a blind bulk push.
Staged rollout turns one bad patch takes down every client
into one bad patch is caught on a canary before it reaches the fleet.
It's the single highest-leverage habit an agency can adopt, and it costs nothing but sequencing.
Rollback and access control at agency scale
Two things separate a hobbyist workflow from an agency-grade one:
Rollback that works under pressure. When a client site breaks, you need recovery measured in seconds, without SSH gymnastics. Release-based deploys keep the last several releases on each server, so reverting is switching the symlink back — the same recovery path on all 40 sites, which is exactly what you want when you're triaging under a client's phone call.
Permissions that match your team. Not every contractor should be able to deploy to every client's production. Team permissions scope who can deploy where, so a junior can ship to staging without holding the keys to 40 production sites — the access-control layer that teams management for agencies is built around. It's also the difference between an audit trail and a shrug when a client asks who changed what.
This isn't hypothetical: a digital agency running client sites on WP Engine moved off manual deploys to a Git-based DeployHQ workflow and got zero-downtime releases across the fleet — the full story is in this agency's WP Engine deployment case study. If WP Engine is your host of choice, the WP Engine deployment guide covers the connection specifics, and there's a general WordPress deployment guide for everything else. Agencies running stores on top of WordPress will also want the WooCommerce deployment guide, where serialized-data migrations and payment config raise the stakes further.
From FTP chaos to a fleet workflow
The shift is less about WordPress and more about treating deployment as an operation you can trust across many sites:
- Git as source of truth on every client site, so drift is a visible diff.
- Off-host builds so shared hosts and missing Composer stop being blockers.
- Templates so 40 sites share one proven pipeline instead of 40 improvised ones.
- Staged rollout so a bad patch dies on a canary, not on your whole roster.
- Atomic releases + one-click rollback so recovery is a symlink switch, not a re-upload.
- Scoped permissions so the right people ship to the right places, with a record.
Agencies that make this shift stop spending Fridays firefighting FTP and start onboarding clients without adding proportional risk — the operational grounding behind why DeployHQ works for web agencies.
If you're managing more WordPress sites than you can safely deploy by hand, the fix is a repeatable pipeline, not a bigger FTP client. See DeployHQ's plans and put every client site on the same reliable release workflow.
Questions about fleet-scale WordPress deployments? Email support@deployhq.com or follow @deployhq on X for deployment tips and product updates.