Back to blog

// OSSeva Blog

Migration

Bitnami Legacy Images: How to Replace the Legacy Repository Without Breaking Your Helm Charts

Randall McClure10 min read

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/bitnami catalog 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 imagesOfficial images
ConfigurationBitnami-specific variables such as POSTGRESQL_*, REDIS_PASSWORD, KAFKA_CFG_*Upstream conventions, such as POSTGRES_* or plain configuration files
Data pathsUnder /bitnami/<app>Upstream defaults, such as /var/lib/postgresql/data
UserNon-root by defaultVaries by image, often root
EntrypointBitnami scripts that render configuration from variablesUpstream 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

  1. Start with stateless components and helper images, in a non-production deployment first.
  2. For stateful workloads, confirm the data path and user ID match before switching, then roll one replica at a time.
  3. Scan the new images and keep the SBOMs; the point of the exercise is to be able to show auditors what is running.
  4. Remove the legacy references entirely, so nothing falls back to bitnamilegacy on 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

BitnamiHelmKubernetesContainer ImagesSupply Chain

Ready to get your open source under control?

Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.