docker-library/redis, the packaging repo behind the redis image on Docker Hub

A packaging repository, and the distinction it insists on

The repository is the Git home of the Docker Official Image for redis, and the README spends its first paragraph on a distinction that trips people up. It is not to be confused with any official redis image provided by redis upstream. The image on Docker Hub under the redis name is maintained by the Docker Community, and the README says so at the top under a heading that reads Maintained by the Docker Community.

That is worth pausing on. Docker Official Images are a specific thing: images built and maintained in the docker-library organisation under a published spec, rather than images published by a vendor under their own namespace. The consequence for a user is that there is a redis image and there may also be a differently scoped image published by the Redis company, and they are not the same artefact.

The second structural fact is where the content actually lives. The full image description on Docker Hub is generated and maintained over in the docker-library/docs repository, specifically in the redis directory. This repository is the source of truth for the image itself.

The README also explains the lifecycle, which is unusual and useful to know. It addresses the question of a change merged here that does not show up on Docker Hub yet, and points at the Docker Library FAQ entry on an image's source changing in Git. It says that for outstanding redis image pull requests, to check the pull requests with the library/redis label on the official-images repository, and that the current source of truth for the image is the library/redis file in the official-images repository.

So there are three artefacts in play. This repository holds the Dockerfiles and scripts, the official-images repository holds the file that declares which versions exist and where they come from, and the docs repository holds the prose that Docker Hub renders. The README is generated too, with a comment at the bottom saying the file is generated by a script in the docker-library/docs repository.

One directory per Redis version

The top level of the repository is the packaging layout, and it is a directory per Redis version: 6.2/, 7.0/, 7.2/, 7.4/ and 7.4-rc/.

The presence of a release candidate directory alongside the released ones is the detail that tells you how this repository handles upstream cadence. Redis versions arrive, and until a release is final there is a directory for the rc build, which is the variant people want to test before it ships. The 7.4-rc/ directory sits alongside 7.4/, so the two coexist in the tree and both are built.

The old versions are kept too, which is the practical point. 6.2/ is a long-deprecated branch and it is still in the repository, which means the Dockerfiles that produce those tags still exist and are still maintained in the sense that they can be rebuilt.

Around the version directories sits the machinery. Dockerfile.template is the template the per-version Dockerfiles are generated from, which is how a change to the base image or the build steps is applied across every version at once rather than being repeated in each file. apply-templates.sh is the script that applies the template, and update.sh is the script that fetches new upstream Redis releases and creates the directory for them. versions.json and versions.sh hold the version metadata and the logic for reading it, and generate-stackbrew-library.sh and generate-stackbrew-library-mac.sh produce the Homebrew formula files, with a stackbrew-generated/ directory where the output lands.

The entrypoint script, docker-entrypoint.sh, is the piece that has the most direct effect on how you run the image, and it is worth understanding before you pass custom arguments to a redis container.

Nine architectures, and two build systems

The build matrix in the README is the part that shows how seriously the project takes portability. There are per-architecture build status badges for amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le and s390x, plus a put-shared badge for the shared layer that the per-architecture images are built on.

That is nine architectures, and the list is more interesting than a list of the usual amd64 and arm64. arm32v5 through arm32v7 cover the older 32-bit ARM boards that a Raspberry Pi or similar device might use. mips64le and ppc64le cover the MIPS and PowerPC machines that are still common in routers and in legacy server fleets. s390x is the IBM mainframe architecture, which is a genuine long tail rather than a token entry. And i386 is the 32-bit x86 build, which still matters for old virtualised environments.

The badges point at two different build systems, and the distinction is worth understanding. The GitHub Actions badge in the first row is a GitHub CI workflow named ci.yml on the master branch, and the Jenkins badges are for an update.sh job and a multiarch job. The update.sh job is the one that picks up a new upstream release, and the multiarch job builds the per-architecture images from it.

That structure explains the whole repository. The update job runs when a new Redis version appears upstream, generates a new version directory from the template, and the multiarch job builds the images for each architecture and pushes the shared layer once. The GitHub Actions workflow appears to cover the ordinary CI checks on the repository itself rather than the image publish.

The practical consequence for a user is that the image is not tied to your architecture's mainstream, and that a new Redis release becomes available as an image without anyone at Redis upstream having to do anything.

The entrypoint, and what the packaging actually buys you

The docker-entrypoint.sh script is the piece of this repository that changes how the container behaves, and it exists for a reason that is worth understanding before you deploy against it.

An official image that ships a server needs a decision about how the user's arguments reach the server. The pattern the entrypoint scripts use is to take the container's command line, and if the first argument looks like a server flag rather than a separate program, prepend the server binary so that docker run redis-server --appendonly yes does what you expect rather than trying to exec a program called docker-server. The redis entrypoint in this repository is the concrete implementation of that pattern, and the same convention is why the README on Docker Hub is the place to read the usage details.

That is the value of this repository in one sentence. The packaging turns a tarball release of the Redis server into something that runs sensibly with a volume mounted for the data, a config file mounted for the configuration, and a command line that behaves the way a Docker user expects.

Two things are explicitly out of scope here. Redis itself, the server, the modules and the licensing of the server, are upstream's business. And the documentation, which lives in the docker-library/docs repository and is rendered on Docker Hub, is where the usage guide, the configuration examples and the contribution notes are kept.

The licence of this repository is BSD-3-Clause, the default branch is master, the last push was on 2026-10-07, and the repository has no GitHub releases, which is consistent with a project whose releases are the images themselves rather than tagged versions of the packaging.

For a reader, the most useful thing to take away is the separation of concerns. If you want to know which Redis versions are packaged, versions.json and the official-images library file are the answer. If you want to know how a version's image is built, the directory named after the version and the Dockerfile.template are the answer. If you want to know how the image behaves, the entrypoint and the Docker Hub page are the answer.

Editorial conclusion

docker-library/redis suits anyone who needs to understand or modify how the redis image is built, since the Dockerfiles, the entrypoint and the update scripts are all here, and it suits an organisation that mirrors the image internally and needs to know how new versions land. It is the wrong place to look for Redis itself, since the image only packages the upstream server, and it is the wrong place to look for the documentation, because the full image description on Docker Hub is generated and maintained in the separate docker-library/docs repository. Before pinning a tag, read the versions.json file to see which Redis versions are actually built, and check the entrypoint script if you run the image with a custom configuration, because that script is what turns your arguments into a redis-server invocation.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. Project website
4. README
5. redis/docker-library-redis on GitHub