Most WordPress sites run on shared hosting or a hand-assembled server, where the PHP version, the plugins and the WordPress core drift over the years into a state nobody can precisely reproduce on another machine. When a bug needs fixing or a plugin needs updating on a site like that, the developer is effectively experimenting on the live server, because there is no matching environment locally.
What goes wrong on a hand-maintained server
Nothing, on any given day. The damage accumulates over years: someone installs a PHP extension because a plugin asked for it; someone raises a time limit because an import kept dying; someone uploads a patched template file over FTP and that patch never reaches version control. The state of the server becomes a sum that nobody wrote down, and half of which no longer remembers itself.
This usually surfaces at the worst possible moment: during a migration, at the end of a PHP major version's life, or when the previous developer is no longer reachable. At that point the site does not need reinstalling, it needs reverse-engineering.
What changes in a container
Packaged into a Docker container, the PHP version, the server configuration and the plugin list are pinned in a single, version-controlled file. The developer starts the exact same container locally that runs in production: not a similar environment, literally the same one.
That has three immediate consequences:
- a plugin update can be tested locally before it goes anywhere near the live site,
- if something breaks, rolling back to the previous image is one command, with no data loss,
- a new developer is productive on the project in half an hour rather than two days.
Content and uploaded files do not live in the image, of course: they sit on a separate volume and in the database. Rolling back affects the code and the environment, never the articles.
Custom code is the sensitive part
This matters even more when the site has custom development on it (a bespoke plugin, a custom theme, an API integration), because that is exactly where “just upload it over FTP and see what happens” is at its most dangerous. There is nothing to return to when it turns out badly.
The containerised version gives you what a modern application has. There is a build step, there is a staging environment, and going live is a well-defined, reversible event rather than an evening of manual work on the server. Updating stops being an act of courage and becomes routine.
What the migration costs
Dockerising isn't free. It requires a thorough audit of which plugins and custom code actually run on the site, what is genuinely in use, and what nobody has opened in years. That is a few days of work, and it usually ends with fewer plugins than it started with.
But those few days are paid once, while the risk of manual, undocumented server management resurfaces with every single update.
When it is not worth it
For a static brochure site where a phone number changes once a year and there is no custom code, containerisation is too much apparatus. The right answer there is a proper backup and a maintained host.
The line sits where the site starts to matter commercially: if downtime costs revenue, or if it carries code we wrote, reversibility is no longer a convenience.
