markshust/docker-magento: a Compose stack for Magento 2 development

The problem: Magento 2 needs six services before you write any code

A Magento 2 install is not a single process. The application expects a web server, a PHP-FPM pool, a relational database, a search engine, a message queue, and usually a full-page cache in front of all of it. On a laptop that means either installing each service natively and keeping the versions aligned with what your Magento release supports, or writing a Compose file that does it. The second option is what this repository is: a set of Dockerfiles and a Compose definition that wire those services together for local development.

The audience is narrow and the README is honest about it. This is for developers working on Magento 2 stores, not for people evaluating Magento or running it in production. If your project is not Magento 2, the stack configuration here has nothing to offer you beyond the general idea of putting services in containers.

How the image tags map to Magento versions

The repository publishes separate Docker Hub images per service rather than one monolith: markoshust/magento-nginx, markoshust/magento-php, markoshust/magento-opensearch, markoshust/magento-elasticsearch, markoshust/magento-rabbitmq, markoshust/magento-varnish and markoshust/ssh. Each image carries version tags, and the README lists them. Nginx is tagged 1.18, 1.22, 1.24, 1.26 and 1.28. PHP is tagged by minor version with an FPM suffix and a build counter, for example 8.1-fpm-9, 8.2-fpm-9, 8.3-fpm-7, 8.4-fpm-2 and 8.5-fpm-0, with a parallel xdebug variant of each.

The search service is where the version matrix matters most, because Magento's supported search backend changed over time. The repository ships both an OpenSearch image (tags 1.2, 2.5, 2.12 and 3) and an Elasticsearch image (7.16, 7.17, 8.4, 8.5, 8.7, 8.11 and 8.13). RabbitMQ is tagged 3.9, 3.11, 3.12, 3.13, 4.1 and 4.2. Varnish has a single tag, 7.7. The practical consequence is that you pick a combination yourself; the tags exist so that the container versions can match what your Magento release declares as supported, and nothing in the repository enforces that match for you.

The top-level layout reflects this split. There is a compose/ directory for the Compose definitions, an images/ directory holding the per-service Dockerfiles, a lib/ directory, and a docs/ directory. The helper commands a developer actually types live in the lib/ and docs/ tree rather than in the README body.

Setting up a Magento 2 project with Docker

The README points at a free screencast course for the full walkthrough, and its curriculum names the steps: install Docker Desktop and configure preferences, run an automated onelinesetup script, or set up Magento manually from a custom Git branch, or configure Docker for an existing Magento project. The repository is cloned into a directory, and the helper scripts are then run from that directory to drive the containers.

The README does not print the clone command or the exact script name in the text available here, so treat the course lecture titled with the onelinesetup script as the authoritative source for that step rather than guessing at a filename. What the curriculum does confirm is the two supported entry points: a fresh Magento install driven by the setup script, and an existing Magento codebase that you point the environment at.

Once the environment is up, the workflow is to run Magento and Composer commands inside the containers rather than on the host. The course lists a lecture on executing bin/magento and composer within Docker containers, which is the pattern the helper scripts wrap. In practice that means you do not need a local PHP installation matching the container's version.

The helper scripts are the interface. The course curriculum separates starting, stopping, restarting and checking container status into its own lecture, which tells you the scripts cover lifecycle management and not just command passthrough. Sample data installation gets its own lecture too, so that is a separate scripted step rather than something folded into the initial setup.

For editor integration, the curriculum includes a PhpStorm lecture on opening a docker-magento project, which implies the PHP interpreter and CLI paths are configured to point at the running container. If you use a different editor, expect to do that wiring yourself; the repository's documentation is built around PhpStorm.

Where this environment stops being the right tool

This is a development configuration. Nothing in the README describes a production deployment path, secret management, image hardening, or a CI pipeline that builds and ships these images. Using the Compose stack as the basis for a live store would mean solving all of that independently, and the image tags are chosen to track Magento's supported matrix rather than to be minimal attack surface.

The second limitation is version coupling. Because each service is tagged separately and the repository does not pin a single known-good combination, an upgrade of Magento that raises the required OpenSearch or Elasticsearch version means you change the tag yourself. The release history shows the project moving quickly, with 53.0.0 in May 2026, 53.0.1 in July 2026 and 53.1.0 in September 2026, so the tags you need are likely to be present, but the responsibility for matching them to your Magento version sits with you.

The README also carries a Known Issues section, which is where platform-specific problems are collected. Anyone on Windows or on Apple Silicon should read that section before starting, because the badge in the README claims Apple Silicon support but the issues list is the place where the caveats live.

How it compares with magento-cloud-docker

The related searches around this project include Magento/magento-cloud-docker-php, and the comparison is worth making explicit because the two solve overlapping problems from opposite directions. magento-cloud-docker is Adobe's own Docker configuration, aimed at reproducing the Magento Cloud environment locally so that what runs on your machine resembles what runs in the hosted platform. The service choices, versions and configuration defaults follow the Cloud stack.

markshust/docker-magento is independent of the Cloud platform. It is Mark Shust's configuration, published under an MIT licence, and it is oriented toward a general local development environment rather than toward parity with a specific hosting product. If your store runs on Magento Cloud and you want local behaviour to match staging, the Adobe configuration is the closer fit. If you run Magento on your own infrastructure, or you want a stack you can read and modify without tracking a hosting product's decisions, this repository is the more direct starting point. The README lists an Alternatives section, so the maintainer acknowledges that other configurations exist.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-21, the same day as the 53.1.0 release. The cadence visible in the release list is roughly every two months, with 53.0.0 in May 2026, 53.0.1 in July 2026 and 53.1.0 in September 2026. Version numbers move by major release, so 53.x is the current line and the default branch is release/next rather than main or master, which is worth knowing before you clone or open a pull request.

The licence is MIT, which permits commercial use and modification with the copyright notice retained. That matters more than usual here because you are likely to fork the Compose files and Dockerfiles for your own project. Keep LICENSE.md in the fork. Nothing in the README states any licence obligation beyond attribution, but if you redistribute the images or the configuration inside a product, the usual practice is to have someone qualified review the notice requirements rather than assume.

The upgrade cost is the version matrix. Because the images are published per service and tagged independently, keeping current means periodically checking whether a newer OpenSearch, Elasticsearch, RabbitMQ or PHP tag exists and whether your Magento version accepts it. The CHANGELOG.md at the repository root is where the release-by-release changes are recorded.

Editorial conclusion

Adopt markshust/docker-magento if you develop Magento 2 on a workstation and want the service stack (Nginx, PHP-FPM, a search engine, RabbitMQ, Varnish) defined for you, with helper scripts for bin/magento and composer. Do not adopt it if you need a production deployment recipe, or if your store is not Magento 2. Before committing, check the docs/ directory for the bin/ helper commands your workflow depends on, and read the Known Issues section of the README for the platform caveats that apply to your machine.

Frequently asked questions

Official sources

1. License: MIT
2. markshust/docker-magento on GitHub
3. Project website
4. README
5. Releases