Okay, picture the scene. It’s Tuesday evening, you’re in pyjamas, and your WordPress site is doing that thing again. A plugin is misbehaving, the database is making suspicious noises, and you really, really need to run WP-CLI without poking the live server with a stick. This is exactly the moment docker-cms exists for — a tiny PHP 8.5 Docker container packed with every WordPress maintenance tool you’ve ever needed, ready in about ten seconds and gone again the minute you close the terminal.
Think of docker-cms as a fully kitted-out WordPress workshop in a box. You wheel it out when something breaks, you do the surgery, you wheel it away. Nothing installed on your laptop, nothing left behind on the server, no mystery binaries hanging around. Just a clean WordPress Docker container that does the job and disappears.
What docker-cms Actually Is (And What It Isn’t)
docker-cms is a PHP 8.5 Docker image built specifically for maintaining and troubleshooting PHP-based CMS installations. WordPress first, obviously, but Drupal, Joomla, ClassicPress, and anything else that runs on PHP works just as happily inside it.
The image ships with a full Angie web server inside (Angie is our hardened NGINX fork), so docker-cms can absolutely serve your WordPress over HTTP if you want it to. But it’s just as happy as a throwaway maintenance sidecar — mount your existing WordPress, drop into a shell, do the admin work, walk away. One image, two jobs: a full runtime when you need it, a disposable toolbox when you don’t.
It’s roughly the difference between fixing your car in a clean workshop and fixing it on the motorway at 80mph. Same car, very different stress level.
What’s Inside the PHP 8.5 Docker WordPress Image?
Every tool I’ve ever reached for during a 2am WordPress emergency is in there:
- PHP 8.5 with all the common extensions you actually use — mbstring, intl, gd, imagick, mysqli, pdo, curl, zip, bcmath, the lot.
- WP-CLI, the Swiss Army knife of WordPress. Update plugins, manage users, run database operations, regenerate thumbnails, dump options, search-replace at scale.
- Composer for modern PHP dependency management.
- MariaDB and MySQL clients for talking to the database directly when WP-CLI isn’t enough.
- PostgreSQL client for the brave souls running WordPress on Postgres.
- Git for theme and plugin version control.
- Node.js, npm and pnpm for theme build steps.
- Xdebug for step-through debugging from VS Code or PHPStorm.
- ImageMagick and WebP tools for regenerating, recompressing or converting media.
- rsync, jq, curl, wget, ripgrep — the usual suspects for moving files around and inspecting JSON.
- SSH client with sane defaults, so you can rsync to remote hosts without faffing with config.
The whole image is about 400 MB compressed, which is small as far as docker images for WordPress maintenance go. Cold-start a shell in under a second once the image is pulled.
Getting Started With docker-cms in Three Commands
1. Pull the docker-cms image
docker pull eilandert/angie-cms:debian
2. Mount your WordPress and open a shell
docker run -it --rm
-v /path/to/wordpress:/wordpress
eilandert/angie-cms:debian bash
You’re now inside the WordPress Docker container, with your live WordPress directory mounted at /wordpress. Files you edit inside the container persist on your host — that’s the point. Tools, PHP, config, environment? All completely isolated. Walk out, container vanishes, your files stay.
3. Start doing useful things with WP-CLI
# List all WordPress users
wp --path=/wordpress user list
# Export the database with today's date in the filename
wp --path=/wordpress db export /wordpress/backup-$(date +%Y%m%d).sql
# Update all plugins at once
wp --path=/wordpress plugin update --all
# Search-replace after a domain migration
wp --path=/wordpress search-replace 'old-domain.com' 'new-domain.com' --skip-columns=guid
That last one — search-replace — is honestly worth the whole image on its own. If you’ve ever tried to change a WordPress site’s domain by hand, you know the pain. WP-CLI handles serialised PHP arrays correctly, which the standard “find and replace in a SQL dump” approach absolutely does not.
Real-World Use Cases for the docker-cms Container
WordPress site migration
Moving a WordPress site between hosts? docker-cms was practically built for this. Export the database, rsync the files, search-replace the domain, import on the other end. The whole migration runs inside the container, on either host, with zero PHP installed on your laptop.
Theme and plugin development with Xdebug
Mount your theme or plugin directory, fire up Xdebug, attach VS Code, and step through your code line by line. It’s the development environment most WordPress devs never bother to set up properly because configuring PHP locally is exhausting. With this PHP 8.5 Docker WordPress image, it’s one docker run away.
Database repairs and bulk cleanups
Six years of WordPress means six years of accumulated rubbish. Spam comments, orphaned post meta, exploding transients, abandoned revisions. WP-CLI eats this stuff for breakfast:
# Nuke every spam comment in one command
wp --path=/wordpress comment delete $(wp --path=/wordpress comment list --status=spam --format=ids) --force
# Wipe expired transients
wp --path=/wordpress transient delete --expired
# Trim post revisions older than 60 days
wp --path=/wordpress post delete $(wp --path=/wordpress post list --post_type=revision --posts_per_page=-1 --before='60 days ago' --format=ids)
# Optimise the database
wp --path=/wordpress db optimize
Debugging a production-only bug safely
The classic “works on staging, dies on production” situation. Mount a copy of the production WordPress directory and database into docker-cms, enable Xdebug, and reproduce the bug in an environment identical to prod — without poking prod itself. This is honestly the sanest way to debug a live WordPress issue without breaking the site for users.
Bulk WordPress operations across many sites
If you maintain a fleet of WordPress sites (agency life, hello), docker-cms with a tiny shell loop will save you hours. Loop over each site directory, mount it, run the same WP-CLI command, exit. Updates, audits, backups, security scans — all scriptable.
Connecting docker-cms to Your Database
If your WordPress database lives in a separate container or on a remote host, pass the connection details as environment variables:
docker run -it --rm
-e WORDPRESS_DB_HOST=db.example.com
-e WORDPRESS_DB_NAME=wp_production
-e WORDPRESS_DB_USER=wpuser
-e WORDPRESS_DB_PASSWORD=secret
-v /path/to/wordpress:/wordpress
eilandert/angie-cms:debian bash
If the database is on a different Docker network, hop on that network with --network:
docker run -it --rm
--network my_wordpress_network
-v /path/to/wordpress:/wordpress
eilandert/angie-cms:debian bash
WordPress reads its own wp-config.php when WP-CLI runs, so if your config is correct on disk, you usually don’t need to set any environment variables at all. The variables above are for cases where you want to override what wp-config says, or you’re running WP-CLI commands that need different credentials.
Important Things to Know Before You Run It
- Production-capable, but think before you ship — docker-cms has a full Angie web server inside, so it can serve HTTP in production. For dedicated hosting we still recommend our slimmer Angie/NGINX-only images alongside it — docker-cms is optimised for the maintenance toolbox first.
- Changes persist on the host — because you mount your real WordPress directory with
-v, any file edits inside the container are real edits on disk. There’s no undo. Back up first, always. - Ephemeral container, real filesystem — use
--rmto auto-clean up the container after exit. The container vanishes; your files stay. - Network access — by default the container reaches the internet (for Composer, npm, etc.), but your database container needs to share a Docker network with it, or you must pass its host IP explicitly.
- Run as root inside, mapped to your user outside — file ownership can get weird if you don’t pass
--user $(id -u):$(id -g). For WordPress directories owned by www-data, that’s normal; for your own dev work, set the user flag.
Frequently Asked Questions
Can I use docker-cms to actually run my WordPress site?
Yes. docker-cms ships with a full Angie web server (our hardened NGINX fork) plus PHP-FPM 8.5, so it can absolutely serve WordPress in production. If you’d rather keep things small and split, our daily-rebuilt NGINX and Angie images pair beautifully with docker-cms running purely as a maintenance sidecar.
Does docker-cms work with Drupal or Joomla?
Yes. docker-cms is a general PHP environment with database clients and Node. WP-CLI is obviously WordPress-specific, but Composer, PHP, the database clients, Git and Node.js work with any PHP CMS. Drupal users can install Drush via Composer inside the container in a single command.
Is PHP 8.5 stable enough for production WordPress?
PHP 8.5 is the current stable release as of 2026. Inside docker-cms it’s perfectly fine for maintenance — you’re not running plugins on it long-term, you’re running WP-CLI commands. Whether your actual production site should be on PHP 8.5 is a separate conversation, and the answer depends on whether all your themes and plugins are 8.5-compatible. Test before you upgrade.
Can I run Xdebug with VS Code through docker-cms?
Yes. Install the PHP Debug extension in VS Code, set it to listen on Xdebug’s default port 9003, and forward the port when you run the container with -p 9003:9003. When PHP runs inside docker-cms, VS Code picks up the connection and you get full step-through debugging with watches and breakpoints.
Does docker-cms respect wp-cli.yml?
Yes. WP-CLI reads wp-cli.yml from your WordPress root automatically. If your wp-cli.yml has a path key set, you can drop the --path=/wordpress flag from every command. Most teams set this once and forget about it.
How do I update the docker-cms image?
Just pull again: docker pull eilandert/angie-cms:debian. The image rebuilds automatically when new PHP point releases drop, and the :latest tag always points at the freshest one. If you want to pin a specific version, check the available tags on Docker Hub.
Is docker-cms safe to run against a live production WordPress?
Technically yes, but be sensible — anything WP-CLI can do, it can do to a live site, including dropping tables. Always run a database export before destructive commands. The container itself doesn’t make production any less safe; you running wp db reset at 3am does. Take the backup, then you’re fine.
Related Posts
- WordPress NGINX + PHP-FPM Configuration Guide — Once docker-cms has cleaned up the database, this guide makes the site actually fast.
- WordPress Hardening Plugin for ModSecurity CRS — Block bots and attackers at the web server, no PHP changes required.
- Angie Web Server: The Complete Guide — The NGINX fork that bundles ACME, JSON API, and dynamic upstreams. A natural front-end for any Docker-hosted WordPress.
Browse all our Docker images.