// OSSeva Blog
MigrationBitnami Legacy Images: How to Replace the Legacy Repository Without Breaking Your Helm Charts
The short answer
On 28 August 2025 Bitnami moved its versioned container images out of docker.io/bitnami and into docker.io/bitnamilegacy, a repository that receives no further updates. The free tier kept only the latest tags of a limited set of images, intended for development. Production Kubernetes estates that pinned versions, which is almost all of them, were left with two choices: repoint every chart at the frozen legacy repository, or replace the images.
Many took the first option as a stopgap and never came back. By September 2026, Docker Hub reported roughly 17 million pulls of bitnamilegacy/postgresql, 15 million of bitnamilegacy/redis, 14 million of bitnamilegacy/kafka, 6 million of bitnamilegacy/rabbitmq and 4 million of bitnamilegacy/mongodb. Every one of those pulls is a container image that has not received a security patch since the move, running a production workload somewhere.
What changed in the Bitnami catalog, and when
- 16 July 2025. Bitnami announced the catalog change in its containers repository on GitHub.
- 28 August 2025. Bitnami moved its versioned container images to a legacy repository,
docker.io/bitnamilegacy, where images no longer receive updates or support. The free tier shrank to free images published at latest tags only. Brownouts of the public catalog followed on several dates in August and September. - 29 September 2025. The public
docker.io/bitnamicatalog was removed. - Now. Maintained, versioned Bitnami images are available through Bitnami Secure Images, Broadcom's commercial offering, which became part of its TrueSource portfolio on 31 August 2026.
For a side-by-side view of every option, see Bitnami alternatives compared, with a replacement guide for each image such as PostgreSQL, Redis and Kafka. For the detail on each step, see what changed at Bitnami and the Bitnami catalogue change.
Step 1: find every Bitnami container image in your deployment
Before choosing an alternative, find out what you actually run. The legacy images hide in more places than the obvious charts. Search running workloads, rendered manifests and values files:
# Images actually running in the cluster
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
| grep -E 'bitnami(legacy)?/' | sort | uniq -c | sort -rn
# Init containers and sidecars are easy to miss
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}' \
| grep -E 'bitnami(legacy)?/' | sort -u
# Values files and rendered charts in your repositories
grep -rnE 'bitnami(legacy)?/|registry: docker.io|repository: bitnami' --include='*.yaml' .
Pay attention to the helper images, not just the main application. Bitnami charts pull images such as os-shell, metrics exporters and kubectl for init containers, jobs and sidecars, and those references are just as frozen.
Step 2: why a straight swap from the bitnami legacy repository breaks
Bitnami images are not interchangeable with the official upstream images. Each Bitnami helm chart was written for Bitnami's conventions, and three of them break on a naive swap:
| Bitnami images | Official images | |
|---|---|---|
| Configuration | Bitnami-specific variables such as POSTGRESQL_*, REDIS_PASSWORD, KAFKA_CFG_* | Upstream conventions, such as POSTGRES_* or plain configuration files |
| Data paths | Under /bitnami/<app> | Upstream defaults, such as /var/lib/postgresql/data |
| User | Non-root by default | Varies by image, often root |
| Entrypoint | Bitnami scripts that render configuration from variables | Upstream entrypoints with different behaviour |
The data path difference is the one that loses data. A persistent volume mounted at /bitnami/postgresql is invisible to an image that expects /var/lib/postgresql/data, so the new pod starts with an empty database.
Step 3: choose a Bitnami alternative
Option 1: official upstream images
Free and maintained, for current versions. You change the chart as well as the image, or move to an operator such as CloudNativePG for PostgreSQL or Strimzi for Kafka. This is the right long-term answer for teams that were going to modernise their charts anyway, and it does not help with versions that are past end of life, because upstream does not publish patched images for those.
Option 2: Bitnami Secure Images
The new Bitnami Secure Images catalog is Broadcom's paid offering. It keeps the Bitnami layout, so charts keep working. It follows upstream version support, and it is sold as a commercial subscription within TrueSource.
Option 3: other hardened image vendors
Docker made its Hardened Images free under Apache 2.0 in December 2025, with a paid Extended Lifecycle Support tier that covers five years past upstream end of life. Chainguard and others publish minimal images. These use their own layouts, so Bitnami charts still need changes, and one drop-in provider, Minimus, is shutting down its registry on 22 October 2026.
Option 4: Bitnami-compatible patched images
Hardened images that keep Bitnami's variables, paths, user and entrypoint behaviour, rebuilt with every security patch, including for end-of-life versions. This is the smallest change to a working chart: repoint image.registry and image.repository, and leave the rest. OSSeva ships these as drop-in images for PostgreSQL, Redis, Kafka, ZooKeeper, RabbitMQ, MongoDB and Elasticsearch.
Step 4: repoint the charts
With a compatible image, the change per chart is a values override:
# values-override.yaml
image:
registry: registry.example.com # your mirror of the replacement images
repository: postgresql
tag: "13.22.0"
global:
security:
allowInsecureImages: true # recent Bitnami charts refuse non-Bitnami images without this
Recent Bitnami charts verify that images come from Bitnami and refuse to render otherwise, which is why the allowInsecureImages flag exists. Set it deliberately, and mirror the replacement images into your own registry so production does not depend on any single public registry again.
Step 5: roll out safely
- Start with stateless components and helper images, in a non-production deployment first.
- For stateful workloads, confirm the data path and user ID match before switching, then roll one replica at a time.
- Scan the new images and keep the SBOMs; the point of the exercise is to be able to show auditors what is running.
- Remove the legacy references entirely, so nothing falls back to
bitnamilegacyon the next deploy.
Frequently asked questions
Are bitnamilegacy images still getting security updates?
No. Bitnami described the legacy repository as receiving no further updates or support. The images still pull, which is why deployments keep working while vulnerabilities accumulate.
What is the best alternative to Bitnami images and Helm charts?
It depends on the versions you run. For current versions, official images with an operator are the cleanest long-term choice. For end-of-life versions, or to keep existing Bitnami images and Helm charts working with a one-line change, use Bitnami-compatible patched images from a vendor that maintains the layout, and mirror them into your own repo.
Will Bitnami Helm charts continue to be maintained?
The charts remain available, but their default image references point at images that are no longer free and versioned. Using them in production means supplying your own images.
How much do Bitnami Secure Images cost?
Broadcom does not publish list pricing; it is sold as a commercial subscription.
What is the quickest fix for ImagePullBackOff after the Bitnami change?
Repointing the image repository from bitnami to bitnamilegacy restores pulls immediately, but leaves you on unmaintained images. Treat it as a stopgap and schedule the replacement.
Tags
Related articles
Migrating RabbitMQ Classic Mirrored Queues to Quorum Queues: The 3.13 to 4.x Guide
September 28, 2026MigrationKafka ZooKeeper to KRaft Migration: The Runbook for Self-Managed 3.x Clusters
September 28, 2026MigrationConfluent Platform 7.x End of Support: What the 7.8 and 7.9 Dates Mean for ZooKeeper Clusters
September 28, 2026Ready to get your open source under control?
Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.