wodby/docker4drupal: a pinned, generated Docker stack for a local Drupal environment

One compose file for the whole stack

Docker4Drupal is a set of Docker images optimized for Drupal, and the way you use it is to take the `compose.yml` file from the latest stable release and use it to spin up a local environment on Linux, macOS or Windows.

That is the whole contract, and it is a deliberate one. The stack is not a set of building blocks you assemble; it is a defined environment that the maintainers generate, test and release together, so that the Drupal version, the PHP version, the database version and the web server version in your local environment are the ones the project decided work together.

The compose file shows how the pieces are wired. The database service uses the MariaDB image with a tag from the environment file, a stop grace period of 30 seconds, and a set of credentials, and it sets `MYSQL_TRANSACTION_ISOLATION` to READ-COMMITTED, with commented lines showing how to add an init script directory and a bind mount for the data directory. The PHP service runs the Drupal PHP image with the tag from the environment, disables the xhprof and spx extensions by default, and turns on `PHP_MAIL_MIXED_LF_AND_CRLF`. Mail is routed to Mailpit on port 1025, with the OpenSMTPD alternative sitting commented next to it.

The commented alternatives are worth noticing, because they are the extension points. The database driver variables, the `DRUSH_OPTIONS_URI` pointing at the local web server, the PHP-FPM user and group, and the Xdebug and PHPUnit configuration for the Drupal test suite are all there as commented blocks, so the same file serves a working default and a configured one.

What the stack contains, and what is on by default

The container table is long, and the enabled by default column is the part that tells you what the compose file actually starts.

Enabled by default are Nginx, the Drupal CMS image, the PHP image running crond, MariaDB, Mailpit, and Traefik as the proxy. Everything else is available but off, and the list of what is off is instructive.

You can switch the web server to Apache 2.4, the CMS to Vanilla Drupal 11 or 10, and the database to PostgreSQL from 18 down to 14. The cache layer is a choice of Valkey, Redis or Memcached. Search is either Solr 9 or OpenSearch 2 with its dashboards, and Vinyl, which is Varnish, is there for the HTTP cache. Node.js 26, 24 or 22 is there for the frontend build, Zookeeper for Solr coordination, and there is a long tail of development tools: Gotenberg for PDF generation, Rsyslog, Webgrind for profiling, an Xhprof viewer, Adminer and phpMyAdmin for the database, OpenSMTPD for a real mail server, and a standalone Selenium Chrome for browser testing.

That list is the real value of the project. A Drupal development environment is not one container, it is twenty decisions about which version of which thing, and this is the set of decisions someone has already made and tested.

The tag scheme is the part you have to understand

The image tags section is the most important documentation in the repository, and it is where a careless upgrade bites you.

Wodby images that package upstream software use a `[VERSION]-r[N]` tag, for example `wodby/mariadb:11.4-r0`. The `11.4` selects the MariaDB version line, and `r0` identifies the Wodby image revision. The warning is explicit: revisions include application updates and image changes, and you should review the image release notes before upgrading, because the revision number does not indicate compatibility.

That is the key sentence. An `r` bump can change anything inside the image, so `r1` is not a patch release in the usual sense, and treating it as one is how a build breaks on a Tuesday.

The rest of the scheme is precise. Major and minor tags share a revision counter per image repository, so `11.4-r0` and `11.8-r0` are siblings in the same repository. Full version tags, such as `11.4.2-r0`, start at `r0` again for each exact upstream version. Matching Git tags identify the source commit for each published revision, which is what makes the images auditable. Development variants retain their qualifier, for example `8.5-dev-r0`.

And the operational advice is short: use the versioned image tags supplied in `.env` instead of floating tags such as `latest`. Previously published tags remain available, so a rollback is a matter of changing one value in one file.

Maintenance is a bot, and there are siblings for every framework

The Maintenance section explains that the images used in the stack are updated regularly and released together, with the full changelog and update instructions on the releases page. Most of the routine updates for the images and for the project itself are performed by a bot, through scripts kept in the separate `wodby/images` repository.

That division is sensible. The images are many, they track many upstream projects, and the updates are mechanical, so a script does them consistently, while the human review happens on the release notes that consumers are told to read.

The project is one of a family. Alongside docker4drupal there are docker4php, docker4laravel, docker4wordpress, docker4ruby and docker4python, which means the conventions you learn here transfer to the others.

The Boundary of the project is stated in the Beyond local environment section. Docker4Drupal is a project 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 answer it gives is to look at the Drupal stack offering on Wodby. So the open source part is the local environment, and that boundary is drawn honestly and early in the document.

The repository, the tests and the state of the project

The tree is small for a stack of this size, because the images live elsewhere. There is `compose.yml` and `compose.override.yml`, a `.env` file that holds the version tags, `traefik.yml` for the proxy configuration, a `Makefile` that includes `docker.mk`, a `tests/` directory, plus the CI configuration and the licence.

The tests are keyed to the versions the stack supports. The Makefile defines `DRUPAL_VER` defaulting to 11 and `PHP_VER` defaulting to 8.5, and the `test` target changes into the test directory for that Drupal version and runs its script with the chosen PHP version. A separate `test-cms` target runs the CMS test suite, and both are marked as phony targets so they never collide with a file of the same name.

That structure is the practical answer to the question of how a stack like this stays honest. The image revisions are automated, and the compatibility of the combination is checked by running the actual test suite against the actual matrix of Drupal and PHP versions, which is a lot more than a stack that merely starts.

On the state of the project, the releases are 6.2.10 from 2026-09-10, 6.2.11 from 2026-09-17 and 6.2.12 from 2026-10-06, and the last push was on 2026-10-15 with the repository not archived. The licence is MIT, and the topics note that the images cover Alpine and arm64 as well as Docker and Docker Compose, which matters for anyone running the stack on an Apple Silicon machine.

Editorial conclusion

Adopt docker4drupal if you develop Drupal and want the local environment to match the versions your target platform runs, since the stack pins a specific upstream line for every component and the compose file is generated by the maintainers rather than written by hand. Do not adopt it as a production platform, because the project says plainly that it is designed to help you spin up a local environment with Docker Compose, and the deployment story it points to is the Drupal stack on Wodby. Verify first that the image tags in the supplied `.env` are the ones you want, because the revision suffix does not signal compatibility and the documentation asks you to read the release notes before upgrading, and that the Drupal and PHP versions match the branches you develop against, since the test targets are keyed to those versions.

Frequently asked questions

Official sources

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