The Bitnami Catalogue Change: What Actually Happened, and What Replaced It

What happened, precisely

The Bitnami catalogue change was announced in the project's own repositories — bitnami/containers issue 83267 and bitnami/charts issue 35164 — and it has three dates worth separating, because they are routinely conflated.

• 28 August 2025. The free catalogue as it had existed stopped. Over the following weeks, existing images including older and versioned tags were moved out of the public catalogue.
• 29 September 2025. The public catalogue deletion date.
• Ongoing. Three repositories now exist where one did: docker.io/bitnami carries a limited set of hardened images on latest tags only; docker.io/bitnamilegacy archives the historical versions; docker.io/bitnamisecure offers hardened community images.

The single most consequential detail is what bitnamilegacy is. The images are there. They pull. They run. They are explicitly unsupported and receive no updates or patches — the announcement describes them as intended for use while planning alternatives. A repository named "legacy" that still serves working images is the most dangerous shape this could have taken, because nothing fails.

Why this broke more than it looked like it would

Bitnami images were rarely a deliberate architectural choice. They were the default that a Helm chart happened to reference. Estates that had never thought about Bitnami as a vendor discovered they depended on it, in three specific ways:

• Pinned version tags. Anything referencing bitnami/postgresql:15.4.0 rather than a floating tag pointed at exactly the class of image that moved.
• Helm chart defaults. Charts specify an image repository and tag in values.yaml. Teams who never overrode those inherited the dependency silently.
• Base images in derived builds. A FROM bitnami/... line in a Dockerfile propagates the dependency into images your own team owns and names.

Find them before deciding anything:

# Running workloads still pulling from the Bitnami namespaces
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | grep -E 'bitnami|bitnamilegacy' | sort | uniq -c | sort -rn

# Helm releases whose chart defaults point there
helm list -A -o json | jq -r '.[] | "\(.namespace)/\(.name)"' \
  | while read r; do
      helm get values "${r##*/}" -n "${r%%/*}" -a 2>/dev/null \
        | grep -qE 'bitnami' && echo "$r"
    done

# Your own images built on top of theirs
grep -rn '^FROM .*bitnami' --include=Dockerfile --include='*.dockerfile' .

The third command is the one that finds the dependencies nobody remembers.

The replacement paths, honestly compared

1. Upstream official images

For most common components there is an official image — postgres, redis, rabbitmq, nginx — maintained by the project or by Docker. Usually the right answer.

The friction is that Bitnami images are not drop-in equivalents of the official ones. Bitnami standardised on non-root execution, a consistent /opt/bitnami layout, and its own environment-variable conventions and init scripts. Moving to an official image means revisiting filesystem paths, user and group IDs, config file locations and any init behaviour you depended on. It is a real migration per component, not a tag change.

2. Another curated catalogue

Several vendors offer hardened image catalogues, and some published Bitnami migration paths when this happened. This solves the immediate problem while preserving the underlying position: your base images come from a single vendor whose commercial decisions you do not control. Worth choosing deliberately this time rather than by chart default.

3. Build your own

More work up front and more control afterwards. Reasonable for a small set of components you genuinely care about, and unreasonable as a blanket policy — a self-built image is one you have now promised to patch.

4. Stay on legacy while you plan

Defensible as a short position, and only as a short position. The images do not change, which means the vulnerabilities in them do not change either. If you take this route, write down the date you will leave and who owns it.

The pattern worth extracting

It would be easy to read this as a story about one vendor. The more useful reading is about defaults.

Almost nobody chose Bitnami. They accepted a chart default, and that default became a production dependency without ever being evaluated as one. The same shape recurs constantly: a base image inherited from a tutorial, a transitive dependency nobody added deliberately, a runtime that arrived bundled with a platform distribution and was never revisited. When the terms change, the surprise is not that a vendor changed them — it is discovering the dependency existed.

The durable lesson is inventory. You cannot make a decision about a dependency you do not know you have, and the gap between "we use X" and "we depend on X" is where these events land.

We have not published figures for what any replacement subscription costs, including Broadcom's. We do not have those numbers from the vendors, and estimates repeated second-hand are not something a security vendor should be circulating as fact. Get a quote against your own estate and compare it.

Where this touches what we do

Several components most affected by the catalogue change are ones we support directly — PostgreSQL, Redis, RabbitMQ, Kafka, Solr. If your Bitnami images pinned versions that are themselves past upstream end of life, you have two problems layered: an image that no longer receives updates, and a version the upstream project no longer patches. The second is the one that persists after you have migrated off the image.

Related

• Exit Bitnami — replacement paths image by image
• SBOMs find your EOL components — they do not fix them
• Redis · PostgreSQL · RabbitMQ