Bitnami Images Moved to bitnamilegacy: Fix ImagePullBackOff and Choose a Replacement

If your Bitnami pods are stuck in ImagePullBackOff, the image tag you reference was most likely moved out of docker.io/bitnami. Broadcom moved existing versioned Bitnami images to docker.io/bitnamilegacy in late 2025, and the free catalog now offers only a small set of latest tags. You can fix it today by repointing charts at bitnami legacy images, but those never get patched, so you also need a replacement plan.

This post walks through the quick fix with commands, then compares the realistic Bitnami alternative Helm charts and images so you can pick a permanent home for each workload.

What did Bitnami actually change?

Bitnami (now part of Broadcom) announced the catalog changes in July 2025 in the bitnami/charts GitHub repository. The key points from that announcement:

• 28 August 2025: the public docker.io/bitnami catalog moved to a limited community subset, and existing images, including older and versioned tags, moved to docker.io/bitnamilegacy.
• Brownouts: Bitnami ran temporary 24-hour outages of selected images in late August and September 2025 to warn users.
• 29 September 2025: planned deletion date for the old public catalog, after being postponed from an earlier date.
• Free tier: a limited set of hardened images under bitnamisecure, on the latest tag only, intended for development.
• Paid tier: Bitnami Secure Images for production use, with version support, LTS branches and SBOMs.

Two details catch teams out. First, the bitnamilegacy page on Docker Hub says the repository “is no longer updated” and “may be removed in the future”. Second, the packaged charts at docker.io/bitnamicharts are still there but no longer updated, and Bitnami says they won’t deploy out of the box unless you override the bundled images.

What stays free: the chart source at github.com/bitnami/charts and the container source at github.com/bitnami/containers remain under Apache 2.0. Sealed Secrets, charts-syncer and minideb were not affected.

How do you confirm Bitnami is the cause of ImagePullBackOff?

Start by describing a failing pod and reading the events:

kubectl describe pod <pod-name> -n <namespace> | sed -n '/Events:/,$p'

If you see “not found” or “manifest unknown” against a docker.io/bitnami/... image, that’s your answer. Pods that are already running keep working until they’re rescheduled to a node without the image cached, which is why this often surfaces during a node upgrade or autoscaling event, not at deploy time.

Next, find every workload that depends on Bitnami images, including init containers:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.initContainers[*]}{.image}{" "}{end}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -i bitnami

Then map images back to Helm releases so you know what to change:

helm list -A
helm get values <release> -n <namespace> -a | grep -iE 'repository|registry|tag'

Don’t forget CI pipelines, Docker Compose files and Dockerfiles that use FROM bitnami/.... They break the same way.

How do you fix ImagePullBackOff today with bitnamilegacy?

Bitnami’s own temporary workaround is to upgrade to the same chart version and point each image at bitnamilegacy. This is the example from the announcement for PostgreSQL:

helm upgrade mypostgres oci://registry-1.docker.io/bitnamicharts/postgresql \
  --version 16.7.0 \
  --set image.repository=bitnamilegacy/postgresql \
  --set volumePermissions.image.repository=bitnamilegacy/os-shell \
  --set metrics.image.repository=bitnamilegacy/postgres-exporter \
  --set global.security.allowInsecureImages=true

The global.security.allowInsecureImages setting is required because the charts check that you’re using the expected images. Each chart has its own repository parameter paths for sidecars, exporters and init containers, so check the chart README rather than guessing. Missing one sidecar image is the most common reason a “fixed” release still fails.

For repeatability, put the overrides in a values file and commit it:

# values-bitnamilegacy.yaml
global:
  security:
    allowInsecureImages: true
image:
  repository: bitnamilegacy/postgresql
volumePermissions:
  image:
    repository: bitnamilegacy/os-shell
metrics:
  image:
    repository: bitnamilegacy/postgres-exporter

Should you mirror bitnamilegacy into your own registry?

Yes, if you’re going to rely on it for more than a few days. Bitnami says the legacy repository may be removed, and you don’t want a rescheduled pod to be the way you find out. Copy the exact tags you run into a registry you control (ECR, ACR, Artifact Registry, Harbor):

crane copy docker.io/bitnamilegacy/postgresql:<your-tag> \
  <your-registry>/mirror/bitnamilegacy/postgresql:<your-tag>

skopeo copy does the same job if that’s what your team already uses. Pin by digest once mirrored, and point your values files at the mirror. This also protects you from Docker Hub pull limits on large clusters.

Be honest about what this buys you: stability, not security. Every CVE published against those images from now on stays unpatched.

What are the realistic Bitnami alternatives?

Here’s how the main options compare, based on what each vendor publishes:

A few notes on each, so the table doesn’t oversell anything.

Official upstream images and charts. Many projects publish their own images and Helm charts or operators. For PostgreSQL, for example, many teams move to an operator such as CloudNativePG rather than a single chart. The catch is that every chart has different values, defaults and security settings, so this is a migration, not a find and replace.

Docker Hardened Images. Docker’s documentation says the community tier’s core features are free to use under Apache 2.0, including hardened minimal images, signed SBOMs, SLSA Build Level 3 provenance, non-root defaults and Helm charts. Full catalog access, FIPS and STIG variants and the 7-day critical CVE fix SLA are in paid tiers. Check that the specific images you need are in the free set.

Chainguard. Chainguard’s free starter tier is a curated list of images on latest and latest-dev tags only. Pinned versions and its Helm charts sit in paid tiers. Great security posture, but budget for it.

Bitnami Secure Images. If you have many Bitnami charts and little time, paying Broadcom is the smallest change. Get a quote and compare it with the engineering cost of migrating.

Build your own. Bitnami’s container source is still Apache 2.0, so you can build and patch the images yourself. That only makes sense if you already run a reliable image pipeline with scanning and rebuilds, because you now own every CVE.

How should you prioritise the migration?

Not every workload needs the same treatment. A sensible order:

1. Internet-facing and stateless services first. These carry the most exposure and are the easiest to swap.
2. Stateful data stores next. Databases, caches and brokers need a data migration plan, a configuration diff and a failover test, so give them proper time.
3. Dev and test environments last. bitnamisecure latest tags may be fine there, which Bitnami itself positions as development use.

Add a guardrail so this doesn’t happen again: an admission policy (Kyverno or OPA Gatekeeper) that only allows images from your approved registries, plus image scanning in CI. Then the next upstream catalog change becomes a ticket, not an outage.

Need help getting off Bitnami?

For teams in Dubai and across the UAE, we run a fixed-scope Helm and image supply-chain remediation sprint. We inventory every Bitnami dependency across clusters and pipelines, stabilise anything at risk with mirrored images, pick a replacement per workload, migrate the highest-risk charts and leave you with registry and admission guardrails. Talk to us about your cluster and we’ll scope it.