WP-CLI and automated deployments: leave FTP in the museum

If your production deploy still starts with an FTP client and a hopeful prayer, you do not have a release process. You have a ritual. Rituals feel productive until one wrong file lands in the wrong folder at 11:47pm and the client Slack channel wakes up.

I have watched this movie on agency projects, university platforms, and ecommerce builds. The plot is always the same. Someone is the hero. The site is the hostage. WP-CLI and a boring deploy pipeline are how you cancel the sequel.

Why FTP fails in ways that look like success

FTP is not evil because it is old. It is dangerous because it hides state. You upload what you think changed. Production keeps the rest. Plugins get half updated. Must-use plugins drift. A CSS file lands, but the PHP that expects it does not. Staging and production quietly become cousins who stop speaking.

Worse, FTP encourages “just fix it live.” That works once. Then it becomes culture. Then nobody knows which version of the theme is real. Git becomes a diary of intentions, not the source of truth.

What WP-CLI actually gives you

WP-CLI is the remote hand that makes WordPress feel like a proper platform. Not a toy CMS. A system you can inspect and change with intention.

In day to day work I use it for the boring jobs that should never depend on a browser click:

• Activating and deactivating plugins in a known order
• Flushing rewrite rules after CPT or route changes
• Search replace across environments with eyes open
• Checking cron events instead of guessing why emails stalled
• Exporting and importing content for controlled migrations
• Clearing caches as part of a release, not as a panic button

The point is not that CLI is cooler. The point is that CLI is repeatable. Repeatable work is what lets a team sleep.

A deploy model that survives traffic

On high traffic WordPress, especially university and media sites, I want three environments that behave like each other on purpose: local, staging, production. Same PHP major. Same object cache strategy where possible. Same plugin set. Same theme build path.

Git is the source of truth. Composer owns PHP dependencies when the project needs them. The theme and custom plugins are not “edited on the server.” They are released.

A release should answer five questions before anyone celebrates:

• What commit is live?
• What database migrations ran?
• What caches were cleared?
• What smoke tests passed?
• Who can roll this back without a detective novel?

If you cannot answer those, you did not deploy. You uploaded hope.

What automation should mean

Automation is not a badge. It is a shorter path to a known good state. For WordPress that usually means:

• Pull request checks for PHP syntax and basic linting
• Build steps for theme assets when you have a frontend build
• Deploy to staging on merge to a release branch
• Manual promotion to production with a checklist, not vibes
• Post deploy WP-CLI tasks that are written down

I am not religious about one CI vendor. GitHub Actions, GitLab CI, Bitbucket Pipelines, or a host native deploy hook can all work. What matters is that humans are not the only people who remember the steps.

What not to automate

Blind database overwrites. Syncing uploads without thinking about media production still needs. Auto merging dependency updates into production on Friday. “Search replace everything” scripts that nobody reviewed.

Automation without judgment ships disasters faster. That is not DevOps. That is acceleration of regret.

A practical starting path if you are still on FTP

You do not need a perfect platform overnight. Start with ownership:

1. Put the theme and custom plugins in Git this week.
2. Stop editing production files directly. Even if the fix is tiny.
3. Make staging a real clone, not a graveyard of old plugins.
4. Write a one page deploy checklist and run it twice.
5. Add WP-CLI to the host and replace three admin clicks with commands.
6. Only then wire CI to do the boring parts for you.

Teams that do this stop treating releases like weather. They become engineering again.

The client facing reason this matters

Clients do not buy your pipeline. They buy uptime, speed, and the feeling that their site will not randomly break after a “small update.” A clean deploy process is how you sell calm. Calm is expensive to fake and cheap to keep once the rails exist.

If your WordPress team still needs a hero at midnight, you do not need more caffeine. You need WP-CLI, Git, and a release habit boring enough to trust.