docker4wordpress is a compose file for a full WordPress stack

One compose file assembles the whole site

docker4wordpress is a set of Docker images optimized for WordPress, and the README says the compose.yml file from the repository spins up a local environment for WordPress on Linux, macOS and Windows. The repository is small and the interesting part is the compose file. At the top level there is compose.yml, a compose.override.yml, a .env file, a traefik.yml, a Makefile and docker.mk, a tests/ directory and the README. The primary language of the project is listed as Makefile, which reflects that the deliverable is a build and orchestration recipe rather than application code. The stack table in the README lists the containers and which are enabled by default. Nginx, WordPress, Crond, MariaDB, Mailpit and Traefik are on by default. Apache, PHP as a separate service, Valkey, Redis, Memcached, Vinyl, Node.js, Solr, OpenSearch, Gotenberg, OpenSMTPD, Rsyslog, Webgrind, the XHProf viewer, Adminer and phpMyAdmin are there to turn on. That default set is the point: a working WordPress with mail capture and a reverse proxy, and everything else one line away.

The compose file is where the wiring is visible

Reading compose.yml tells you more than the table does, because it shows how the services find each other and where the data is expected to live. The database service is the clearest example:

  mariadb:
    image: wodby/mariadb:$MARIADB_TAG
    container_name: "${PROJECT_NAME}_mariadb"
    stop_grace_period: 30s
    environment:
      MYSQL_ROOT_PASSWORD: $DB_ROOT_PASSWORD
      MYSQL_DATABASE: $DB_NAME
      MYSQL_USER: $DB_USER
      MYSQL_PASSWORD: $DB_PASSWORD

Every image is selected through a tag variable rather than a literal, which is what makes the stack reproducible and upgradable. The credentials come from environment variables, and the container names are prefixed with the project name so several stacks can run side by side on one machine. The commented out volumes block under the database service shows two intended patterns, mounting an init directory for .sql files and mounting a host path for the data directory, with the note that it is there when you want to manage volumes manually. That is a small example of the file's character. The stack ships with sensible defaults and every deviation is visible as a commented line you can uncomment, rather than something you discover in a wiki.

Mail and cron are wired in from the start

Two of the default-on services exist because a local WordPress is annoying without them. Mailpit is enabled by default and the PHP service is configured to deliver through it, with MSMTP_HOST set to mailpit and MSMTP_PORT set to 1025, and the commented alternative shows the OpenSMTPD path with port 25. In practice that means a WordPress plugin that sends mail does not try to reach a real mail server, and you can read what it sent in a web interface instead of hunting through logs. The Crond container runs the same wodby/wordpress-php image as the PHP service, with init set to true, and its CRONTAB entry is the WordPress cron invocation on the hour. WordPress scheduled tasks therefore run in the local stack as they would in production, which is the kind of detail that prevents a bug that only appears after deployment. The PHP_EXTENSIONS_DISABLE setting lists xhprof and spx, with a comment noting that the xdebug extension is also disabled by default, and the commented lines below show the xdebug mode settings for debug, profile, and the IDE key, along with the PHP_IDE_CONFIG line.

The code directory is mounted, not copied

The PHP service mounts the current directory into the container, with a cached volume mapping the project onto the web root, and there is a commented alternative for macOS users pointing at Mutagen, with a note that a named volume can be used instead. Mounting the working copy rather than baking it into an image is what makes this a development environment. Edit a plugin, save the file, and the change is live in the container with no rebuild step. The comment also notes that a separate files volume exists for XHProf and Xdebug profiler traces, which is the mechanism behind the Webgrind and XHProf viewer containers in the table. Traefik handles ingress and is enabled by default, with its configuration in the separate traefik.yml file, and the stack's internal service names are prefixed with the project name so that several copies can share one host without their hostnames colliding. On a Mac, the file watching and sync behaviour is the part most likely to need the Mutagen path, which is why the project links to its documentation rather than assuming the bind mount behaves the same on every platform.

Image tags are versioned, and revisions do not mean compatibility

The tag policy is described in detail and it is the section worth reading before you touch the .env file. Wodby images that package upstream software use a VERSION-rN tag, for example wodby/mariadb:11.4-r0, where 11.4 selects the MariaDB version line and r0 identifies the Wodby image revision. Revisions include application updates and image changes, and the documentation tells you to review the image release notes before upgrading, because the revision number does not indicate compatibility. That caveat is the important part. A revision bump can change the behaviour of the software inside the image without any change in the upstream version, so treating r0 to r1 as a patch is a mistake. Two more rules follow. Major and minor tags share a revision counter per image repository, while full version tags such as 11.4.2-r0 start at r0 again for each exact upstream version. And matching Git tags identify the source commit for each published revision, so you can trace an image back to the code that built it. The instruction is to use the versioned image tags supplied in .env instead of floating tags such as latest, and the note that previously published tags remain available is what makes a rollback possible.

Optional services are the reason the table is long

The long container list is not padding. Each optional service covers a distinct thing a WordPress developer eventually needs. Caching has three separate options, Valkey, Redis and Memcached, so you can match what your host provider uses rather than guessing. Vinyl, the Varnish based image, is a page cache in front of PHP for a local site that feels slow. Node.js at versions 26, 24 and 22 is there for a build step, and the Node.js topic on the repository is worth noting because many themes and plugins now ship a build pipeline. Solr, OpenSearch and OpenSearch Dashboards cover search, and OpenSearch Dashboards gives you a query interface. Adminer and phpMyAdmin are two database clients so you can look at rows without a desktop client. Gotenberg turns the container into a PDF generation service, which some themes need for invoices or exports. Rsyslog gives you log collection, and Webgrind and the XHProf viewer are PHP profilers with a web interface. The structure means you enable a capability by adding a service, not by writing configuration, and the compose file documents the wiring for each as a commented block.

Maintenance, tests and where this stops

The project is not archived and the last push was on 2026-10-20, with releases 6.2.12 on 2026-10-06, 6.2.11 on 2026-09-17 and 6.2.10 on 2026-09-10. The README says the images used in the stack are updated regularly and released together, with the changelog and update instructions on the releases page, and that most routine updates for the images and the project are performed by a bot through scripts in the wodby/images repository. That is worth understanding, because it means the compose file and the images move on a schedule you do not control, and a pull that looks trivial can change the PHP or MariaDB version under you. There is a test target in the Makefile, which includes docker.mk and runs the test suite in the tests/ directory with a PHP_VER variable defaulting to 8.5, so the stack can be exercised against more than one PHP version. The scope limit is stated plainly in the README. Docker4WordPress is designed to help you spin up a local environment with Docker Compose, and if you want to deploy a consistent stack with orchestrations to your own server, the project points at the Wodby hosted WordPress stack instead. The licence is MIT, so the compose file and any changes you make to it are yours to use as you like.

Editorial conclusion

Adopt docker4wordpress when you need a local WordPress that matches a colleague's environment exactly, when you want mail, cron and profiling available without configuring them, and when you can read the compose file to understand what runs. Do not adopt it as your production deployment, since the project says it is designed to spin up a local environment with Docker Compose and points to Wodby for orchestrated hosting. Verify first that the image tags in the supplied .env pin the versions you want rather than floating ones, that the PHP version you develop against is the one selected by the tag you keep, and that you have read the image revision policy before bumping a tag.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wodby/docker4wordpress on GitHub