Bitnami changed its public catalog in 2025: most container images moved to a legacy archive that gets no updates, and supported images moved to a paid offering. If your Helm charts still pull from docker.io/bitnami, audit them now, mirror what you must keep, and plan a supported replacement.
What actually changed?
The facts below come from Bitnami's own announcement thread in its charts repository, opened on 16 July 2025 and now closed. We are summarising it as of our fetch on 18 October 2026, and the registry may have moved on since, so check it before acting.
The announcement said that from 28 August 2025 the public catalog would switch to a limited set of hardened community images, available only on the latest tag and intended for development. Existing images, including versioned tags, would move to a Bitnami Legacy repository at docker.io/bitnamilegacy. That archive receives no further updates or support and is meant only as a temporary migration aid. Production grade images, with continuous rebuilds, SBOMs and long term support branches, would sit under a paid subscription called Bitnami Secure Images.
A banner on the thread says the deletion of the public catalog was postponed to 29 September 2025, with scheduled 24 hour brownouts of sets of ten images to warn users.
Two things stayed in place. The source code for the container images and Helm charts remains on GitHub under the Apache 2.0 license. And already packaged OCI charts remain at docker.io/bitnamicharts, but receive no updates and, per the FAQ, will not work out of the box unless you override the bundled images.
What is the risk in doing nothing?
Two different risks. If images disappear from the path your chart uses, new pods fail to pull and a restart becomes an outage. And if you move to the legacy archive, you keep running without security patches. The announcement itself calls the archive temporary. A database image frozen in 2025 gains known vulnerabilities every month.
A constructed example
A team runs PostgreSQL and Redis from Bitnami charts in four clusters. A node restart in staging fails with an image pull error.
They take three steps over two weeks. Day one, they inventory every image reference in all clusters with a script that lists running images and their registries. Day two, they mirror the exact tags currently running into their own registry by digest, so nothing can disappear from under them. Over the next sprint they pick supported replacements for each component and schedule upgrades. The mirror bought time; the replacement fixed the real problem.
How do you find what you depend on?
List images from the cluster, not from your memory:
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u
Then search your chart values and CI pipelines for bitnami in repository fields. Bitnami's own workaround uses helm upgrade with the same chart version and a set flag pointing each image repository parameter at bitnamilegacy. The thread describes it as temporary.
What are your options for a permanent fix?
- Pay for the supported catalog. This keeps the same charts and adds patches.
- Switch to upstream charts or images maintained by the project itself, where one exists, and test the differences in configuration keys.
- Build from the Apache 2.0 source into your own registry. This gives control and makes you responsible for rebuilds and patching.
- Replace the component, for example with a managed service.
Helm's documentation recommends OCI capable registries to store and share chart packages, and lists several hosted ones, so mirroring charts and images into a registry you control is a supported pattern.
How do you keep this from happening again?
Treat third party registries as a dependency with a lifecycle. Mirror critical images into your own registry, pin them by digest rather than tag, scan them on a schedule and record each one in your SBOM. Safeguard's SBOM and dependency scanning can show which images and packages a deployment includes, and policies and gates can block unpatched or unsupported ones from shipping.
How to check or apply this
- List every image running in every cluster, with its registry.
- Search charts, values files and pipelines for bitnami references.
- Mirror the exact tags in use into your registry, pinned by digest.
- Point charts at the mirror with explicit repository overrides.
- Choose a supported replacement for each component and set a date.
- Scan the mirrored images and track their vulnerabilities.
- Add a policy: no production image from an unsupported or unpinned source.
Quick check
Is the legacy repository safe for production?
Bitnami describes it as an archive with no updates or support, for temporary migration use. Plan to leave it.
Can I still use the chart source code?
The announcement says chart and container source remains on GitHub under Apache 2.0. Images then have to come from somewhere you trust or build.
Sources
- Bitnami charts, Upcoming changes to the Bitnami catalog (issue 35164)
- Helm documentation, Use OCI-based registries
Last reviewed: 18 October 2026.
