The Docker Official Image for RabbitMQ is a template and version tree

An image built from source, not the image itself

The first thing the README settles is what this repository is. It is the Git repo of the Docker Official Image for `rabbitmq`, and it is maintained by the Docker Community. The README is careful to add a warning that this is not to be confused with any official `rabbitmq` image provided by `rabbitmq` upstream, which matters if you have been pulling from a different namespace and assumed the contents matched. So the artefact people actually run on Docker Hub is generated from the files here. The published documentation for the image is a separate thing again: the README says the full image description on Docker Hub is generated and maintained over in the docker-library/docs repository, specifically in the `rabbitmq` directory there. The README in this repository is itself generated, by a script in that same docs repository.

One directory per RabbitMQ minor version

The repository layout is where the real content lives. At the top level there are directories for RabbitMQ versions `4.0`, `4.1`, `4.2`, `4.3` and `4.4`, which is how the image keeps several supported release lines built from one set of definitions. Alongside them sit three Dockerfile templates, `Dockerfile-alpine.template`, `Dockerfile-management.template` and `Dockerfile-ubuntu.template`, which is the clearest statement of the image's product matrix: an Alpine base, a variant with the management plugin, and a Ubuntu base. The names of the directories and templates also tell you the shape of the versioning policy, since a new RabbitMQ minor release is a new directory and a new tag rather than an in-place change to an existing one. A reader who wants to know what changed between two RabbitMQ versions can compare the two directories rather than diffing image layers.

Templates, versions.json and the refresh scripts

The build machinery is visible in the file names. `apply-templates.sh` sits at the top level, which is where you would look to understand how a template is turned into a buildable Dockerfile for a given version directory, since the templates are not the files that are built directly. The version metadata lives in `versions.json`, with `versions.sh` next to it, and those two are what tie a tag on Docker Hub to a RabbitMQ version and a base image choice. Two more scripts complete the picture. `update.sh` handles the refresh of the image definitions, and `generate-stackbrew-library.sh` covers the generation of the library entries used by the official-images mechanism, which is how the same definitions are registered for publication as official image tags. None of this is RabbitMQ configuration. It is the packaging pipeline around the broker, and keeping it separate is what lets the same repository serve several distributions.

docker-entrypoint.sh and the conf.d directory

Two entries in the tree determine what happens when the container starts. `docker-entrypoint.sh` is the entrypoint of the image, and `conf.d/` is a directory of configuration fragments shipped with it. The presence of a `conf.d` directory alongside an entrypoint is a specific design choice rather than a generic one, because it lets a configuration file be dropped in as a separate file and read at startup, instead of requiring the operator to replace a single monolithic configuration file. That is the mechanism that makes the image workable with configuration management systems, where a directory of fragments fits the model better than one file. The README does not document the contents of the entrypoint or the naming rules for the fragments, so the concrete set of supported settings has to be read from the files themselves, and the Docker Hub documentation is the place the upstream project describes them.

From a merged pull request to a published tag

The README spends most of its text on the lifecycle, and that is where the practical answers are for anyone wondering why their image tag has not moved yet. It links an FAQ entry on the official images change lifecycle, described as an image's source changed in Git, now what, which explains the sequence. It also points out where to look for outstanding `rabbitmq` image pull requests, namely the ones carrying the `library/rabbitmq` label on the official-images repository, and it names the current source of truth for `rabbitmq`, the `library/rabbitmq` file in that same official-images repository. The workflow is therefore a two repository arrangement. A change lands in this repository, the official-images repository holds the definition that maps tags to build recipes, and the pull request label is how you check whether your change is still queued.

Where the real documentation lives

It is worth being blunt about this, because it is the most common source of confusion for anyone arriving at the repository. The README here is a stub. It links to the Docker Hub page for the full readme on how to use the image, and for information regarding contributing and issues. The generated marker at the bottom of the file names the script that produces it. So if you arrive expecting configuration reference, troubleshooting advice or an issues tracker, you are in the wrong file, and the answer is to read the `rabbitmq` directory of the docker-library/docs repository and the Docker Hub page instead. For a project that people treat as infrastructure, that split is normal for the Official Images programme, and it also means that the community around this image is organised around Docker Hub discussions and the official-images repository rather than around this repository's issue tracker.

MIT licensed, no releases, and an active branch

The licence file in the repository is MIT, which in short terms allows use, modification and redistribution with the notice preserved. There are no GitHub releases for this repository, and that is expected rather than an oversight, because the artefacts of this project are the image tags on Docker Hub, not versioned archives. The repository is not archived, and the last push was on 2026-10-20, so the templates, the version directories and the scripts are being changed as RabbitMQ ships new releases. The rest of the tree is the standard plumbing of the programme, with a `.github/` directory for the workflows, a `.gitattributes` file, a `.gitignore`, and a `LICENSE` file. There is also a `documentation`-shaped absence worth noting, since the documentation is deliberately hosted in the separate docs repository rather than in this one.

Editorial conclusion

Adopt this repository as your reference when you need to see what the published RabbitMQ image actually contains, since it is the Git source for the Docker Official Image and holds the templates, the per-version directories and the entrypoint that shape the result. Do not expect it to be a place to file image bugs, because the README directs issues and contributions to Docker Hub and the documentation repository, and the source of truth for the image definition sits in the official-images repository. Verify first which RabbitMQ version line you need, since the tree carries directories for 4.0 through 4.4, and read the entrypoint and `conf.d/` handling before assuming a configuration file lands where you expect.

Frequently asked questions

Official sources

1. docker-library/rabbitmq on GitHub
2. Issues
3. License: MIT
4. Project website
5. README