bitnami/containers: prebuilt Docker images for open source applications

What bitnami/containers actually packages

The repository is a library of Dockerfiles and supporting files, one directory per application, holding the recipes for images published under the bitnami organization on Docker Hub. The README describes the result as "Popular applications, provided by Bitnami, containerized and ready to launch." The intended reader is someone who needs to run a well-known open source application in a container and does not want to write and maintain the image build themselves.

The scope is deliberately broad rather than deep. There is no single flagship image; the value is the catalogue and the consistency of layout across it. Each application directory carries the files needed to build the image and, according to the README, a functional docker-compose.yml at the main folder of each application. That uniformity is the product: once you understand one application's directory, you understand the shape of the others.

One thing the README makes explicit is generational. The images described here are the current generation, and the README points readers looking for the previous Debian-based generation to the Bitnami Legacy registry on Docker Hub. If you are migrating from older Bitnami images, that distinction matters more than any individual tag.

Pull, tag and build: how an image reaches your host

The path from repository to running container has two branches. The first is pulling a prebuilt image from Docker Hub, which the README calls the recommended way. The second is building locally from the Dockerfile in the repository, for people who want to modify the image or reproduce a build.

The pull path uses the bitnami namespace and an application placeholder. The README gives this example:

docker pull bitnami/APP

Replace APP with the application name you want, and the command fetches the default tag for that application. For a pinned version, the README shows a versioned tag form:

docker pull bitnami/APP:[TAG]

The tag is not optional decoration. Pulling without one means you follow whatever the default tag points at, and the README does not document a rollback procedure for a tag that changes underneath you. Pinning is the only mechanism the documentation offers for reproducibility.

The build path clones the repository and builds from the application directory. The README's example uses three placeholder segments, APP, VERSION and OPERATING-SYSTEM, which map to the directory structure under bitnami/:

git clone https://github.com/bitnami/containers.git
cd bitnami/APP/VERSION/OPERATING-SYSTEM
docker build -t bitnami/APP .

Because the path includes both a version and an operating system segment, the repository keeps more than one build target per application. That is a layout decision worth noticing: the same application can exist at multiple version and OS combinations, and you have to know which directory you want before the build command means anything.

Running an application with the bundled Compose file

For a first real run, the README's Docker Compose route is the shortest path because it avoids writing a Compose file yourself. The command fetches the application's docker-compose.yml from the repository's main branch and writes it to your working directory:

curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/APP/docker-compose.yml > docker-compose.yml
docker-compose up -d

Substitute the application name for APP. After the second command, the container starts detached and you should see Compose report the created container and network. To confirm what is running, docker ps lists it; to read startup output, docker-compose logs follows it.

Two cautions follow from the README rather than from anything hidden. First, the fetched Compose file comes from the main branch, so it reflects the current state of the repository, not a release you selected. If you need the Compose file to match a pinned image tag, review it before running it and adjust the image reference. Second, the README does not document what ports or volumes the generated file exposes for a given application; that information lives in the file itself, so read it before exposing anything to a network.

Scanning happens in the pipeline, not on your machine

The README states that images are analyzed for vulnerabilities as part of the release process, using Trivy and Grype, and that the scan is triggered by a GitHub action for every pull request affecting container source code, regardless of origin. That is a build-time control. It tells you a scan ran before publication; it does not tell you what the scan found for the tag you pulled, and the README does not describe how results are surfaced to users of the free images.

This is where the boundary between the free library and the commercial tier becomes concrete. The README's security narrative, near-zero vulnerabilities, VEX statements, KEV and EPSS scores, FIPS and STIG options, air-gap support, SBOM and in-toto provenance attestation, is attached to Bitnami Secure Images, which it says are built on Photon Linux. The README also notes that some catalog data is only available with commercial subscriptions to BSI. So the free images in this repository and the hardened images described in the same document are not the same artifact, even though the README presents them in one flow.

If your requirement is a documented vulnerability posture with attestation, the free pull command is not the thing you are looking for. The repository supplies the build recipes and the pipeline scans; the metadata layer is elsewhere.

Deprecation, archived repositories and the cost of waiting

The retention policy is the part of the README with the sharpest operational consequences. Deprecated assets stay in the Bitnami Docker Hub organization unchanged for at least six months after deprecation. After that, all images move to an archived repository: an asset named foo previously at bitnami/foo moves to bitnami/foo-archived and remains there indefinitely. Images the README calls special, naming bitnami/bitnami-shell and bitnami/sealed-secrets because Helm charts use them extensively, get an extended coexistence period of one year.

The practical effect is that a tag you pin today can change location without changing content. A reference to bitnami/foo will stop resolving to the images once the move happens, and you would need to update to bitnami/foo-archived. Nothing in the README suggests the old path keeps working as an alias, and it does not document a notification mechanism for deprecation. If you run these images in production, tracking deprecation announcements is your responsibility.

The licence situation is separate and worth reading carefully. The README states the repository is licensed under the Apache License, Version 2.0, with copyright held by Broadcom, and that it is distributed on an AS IS basis without warranties or conditions of any kind. The repository metadata reports the licence as NOASSERTION, so the README's Apache 2.0 statement is the clearer signal. That covers the repository contents; it does not by itself settle the licensing of every application packaged inside an image, which is a question for whoever operates the deployment.

When a single application image beats this library

The obvious alternative is the upstream project's own official image on Docker Hub. The difference in approach is ownership of the build. With an official image, the application's maintainers define the base, the entrypoint and the tag policy. With bitnami/containers, Bitnami defines them across a catalogue, which buys consistency between applications but means the image is a repackaging rather than the reference artifact.

A second alternative is building your own image from the application's release artifacts. That is more work and puts patching on you, but it also removes the dependency on Bitnami's tag lifecycle and on the six-month deprecation window described above. If you already have a base image standard, an internal registry and a patching cadence, the library's main advantage, not having to write the Dockerfile, is the part you have already solved.

The README's own pointer to the Bitnami Legacy registry is a third option for existing deployments. If your stack was built on the previous Debian-based generation, moving to the current images is a migration, not a tag bump, and the legacy registry exists so that migration does not have to happen on the same day as an upgrade.

Who should pull from bitnami/containers

Use this repository when you want a common open source application running quickly, you are comfortable with Docker and Compose, and you intend to pin tags and track deprecation yourself. The per-application docker-compose.yml and the uniform directory layout reduce the setup work to a pull and an up command, which is the whole proposition.

Look elsewhere if your requirements include documented vulnerability triage, FIPS or STIG compliance, air-gapped operation or supply chain attestation. The README places those capabilities in Bitnami Secure Images, and the free images in this repository are not described as carrying them. Look elsewhere too if you cannot accept a tag that may relocate to a bitnami/foo-archived repository after the retention window, or if you need a guaranteed support relationship with the image publisher.

Before you commit, check three things in the repository itself: that the application directory you need exists under bitnami/ with a version and operating system combination you can build, what the fetched docker-compose.yml actually exposes, and whether the image you pull is the current generation or the Debian-based one the README redirects to the legacy registry. Those three checks answer most of what the README leaves open.

Editorial conclusion

Adopt bitnami/containers if you want to run a common open source application in Docker without assembling a Dockerfile, and you accept that the hardened Photon Linux base, VEX statements, FIPS and STIG options and SBOM attestation described in the README belong to the commercial Secure Images tier rather than the free images. Do not adopt it if you need long-lived tags for a deprecated application: the retention policy moves images to a bitnami/foo-archived repository after at least six months, with a one-year window for images such as bitnami/bitnami-shell and bitnami/sealed-secrets that Helm charts depend on. Before committing, check the application directory you need under bitnami/ in the repository, confirm the docker-compose.yml in that folder is current, and decide whether the free image or a BSI subscription matches your compliance requirements.

Frequently asked questions

Official sources

1. bitnami/containers on GitHub
2. Issues
3. Project website
4. README