Fixing ImagePullBackOff After Bitnami Moved Images to bitnamilegacy

The short answer

If a pod that runs a Bitnami image is stuck in ImagePullBackOff, the tag it asks for has most likely been deleted. Bitnami removed versioned tags from docker.io/bitnami on 29 September 2025, and that repository now serves only latest. The fastest fix is to point every image in the release at docker.io/bitnamilegacy, which holds copies of the old tags, and set global.security.allowInsecureImages=true so the chart accepts them.

That gets the pod running today, on an image that will never be patched again. Bitnami describes the legacy repository as receiving "no further updates or support", and its newest tags date from 28 August 2025. Treat the repoint as a stopgap and schedule the replacement.

What changed at Bitnami, and when

• 16 July 2025. Bitnami announced the catalogue change in bitnami/containers issue 83267 and bitnami/charts issue 35164.
• 28 August 2025. Bitnami stopped publishing new versioned images to Docker Hub. Copies of the existing tags went to docker.io/bitnamilegacy, which has not been updated since.
• 28 August to 19 September 2025. Three brownouts made sets of images temporarily unavailable, so pulls failed for a day or two at a time before the final deletion.
• 29 September 2025. Versioned tags were deleted from docker.io/bitnami. The deletion was first planned for 28 August and postponed. What remains there is a small community subset on latest tags, for development.

Not every old tag was copied. Bitnami said images based on distributions deprecated for more than three years, with tags such as debian-10, centos-7 and ol-7, would not move to the legacy repository. On 6 October 2026, bitnamilegacy/postgresql has no debian-10 tags at all. A chart that defaulted to one of those, which includes older PostgreSQL 11 charts, has nothing in bitnamilegacy to repoint to. For background, see the Bitnami catalogue change and what changed at Bitnami.

How to diagnose it

Find the failing pods and read the events on one of them:

# Pods that cannot pull their image, in every namespace
kubectl get pods -A | grep -E 'ImagePullBackOff|ErrImagePull'

# The Events section names the exact image and the registry's answer
kubectl describe pod my-postgresql-0 -n data

Kubernetes defines ImagePullBackOff as a container that could not start because the image could not be pulled, and it retries with a growing delay of up to five minutes. The cause is in the events. For a deleted Bitnami tag, the registry answers that the manifest is unknown, and the runtime reports it as not found. Credentials are not the problem here, and adding pull secrets will not help.

Then list every Bitnami reference in the cluster, including init containers, because a chart's helper images break the same way:

# Every image reference, main containers and init containers
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}' \
  | grep -E 'bitnami/' | sort | uniq -c | sort -rn

# Confirm a tag is gone (manifest unknown) and see whether a legacy copy exists
docker manifest inspect docker.io/bitnami/postgresql:16.4.0-debian-12-r0
docker manifest inspect docker.io/bitnamilegacy/postgresql:16.4.0-debian-12-r0

Look for os-shell, which Bitnami charts use for volume permissions, and the metrics exporters as well as the main image. All of them pulled from docker.io/bitnami.

The immediate fix: repoint the release to bitnamilegacy

Bitnami's own announcement gives the procedure: upgrade to the same chart version and change the repository of each container image to the legacy one. Its example, 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

Use the chart version you already run (helm list -n <namespace> shows it) and keep your existing values with --reuse-values or your values file. Changing the chart version during an incident can change the database major version, which is a different and riskier operation.

Do you need allowInsecureImages?

On many chart versions, yes. On 10 December 2024 Bitnami released a minor version of every chart with a check, in the bitnami/common library chart from 2.28.0, that fails the render when an original image is replaced:

ERROR: Original containers have been substituted for unrecognized ones. Deploying this chart
with non-standard containers is likely to cause degraded security and performance, broken chart
features, and missing environment variables.

Our reading of the template is that charts built with common 2.28.0 to 2.31.3 fail on any substituted image, including bitnamilegacy; from common 2.31.4, released on 12 August 2025, images under docker.io/bitnamilegacy produce a warning instead; and charts built before 2.28.0 have no check. To see which common version your chart carries:

helm pull oci://registry-1.docker.io/bitnamicharts/postgresql --version 16.7.0 --untar
grep '^version' postgresql/charts/common/Chart.yaml

Setting the flag on a chart that does not check it does nothing, which is why Bitnami's example sets it unconditionally. For an image that is not from Bitnami at all, such as a replacement image from another registry, the check fails on every chart from 2.28.0 onwards unless the flag is set.

When there is no legacy copy

If docker manifest inspect finds no bitnamilegacy tag, as with the debian-10 images, there is no quick repoint. Use a tag from a newer Debian base on the same application version if one exists in bitnamilegacy, or move straight to one of the longer-term options below. Do not change the database major version just to find a tag that pulls.

Why bitnamilegacy is a stopgap

• It is frozen. bitnamilegacy/postgresql was last updated on 29 August 2025, and the Redis, MongoDB and os-shell repositories stopped in the same week. Every vulnerability disclosed since then is still in those images.
• Bitnami says so. The announcement says the legacy catalogue "should only be used for temporary migration purposes", and a Broadcom post from August 2025 says "we do not plan to keep this registry around for long". No removal date has been published.
• Nothing warns you. The images keep pulling and running, so the risk stays invisible until a scanner or an auditor finds it. Our bitnamilegacy replacement guide covers the inventory in more detail.

Whatever you pick next, mirror the images into a registry you control. Production that pulled straight from Docker Hub is how one vendor's catalogue decision became an outage.

Longer-term options

OSSeva's drop-in images keep Bitnami's environment variables, /bitnami data paths and non-root user, and are patched for versions past upstream end of life: PostgreSQL 11 to 14, Redis 6.x and 7.2, Kafka 2.8 to 3.9 including ZooKeeper-mode clusters, ZooKeeper 3.5 to 3.8, RabbitMQ 3.8 to 3.13, MongoDB 4.2 to 6.0, and Elasticsearch 7.10.2 and 7.17. Each per-image page, such as Kafka or RabbitMQ, lists the chart values and the chart versions for each application line. For how the hardened catalogues treat end-of-life versions, see Chainguard vs Docker Hardened Images vs Bitnami Secure Images.

Frequently asked questions

How do I fix ImagePullBackOff after Bitnami moved images to bitnamilegacy?

Run helm upgrade on the same chart version with each image repository changed from bitnami/... to bitnamilegacy/..., including os-shell and any exporters, and set global.security.allowInsecureImages=true. Check first with docker manifest inspect that the legacy tag exists; tags on debian-10 and older bases were never copied.

Why did my Bitnami pods suddenly fail to pull?

Bitnami deleted versioned tags from docker.io/bitnami on 29 September 2025, after brownouts in August and September. Any pod that restarts or reschedules onto a node without the image cached asks for a tag that no longer exists.

Are Bitnami images still free?

Only a limited set, on latest tags, intended for development. Versioned, maintained images are sold as Bitnami Secure Images, and the free bitnamilegacy copies are frozen.

Are bitnamilegacy images still receiving security updates?

No. Bitnami says the legacy catalogue will receive no further updates or support, and the newest bitnamilegacy/postgresql tags date from 28 August 2025.

Is global.security.allowInsecureImages safe to set?

It only switches off the chart's check that images are Bitnami's own. It does not change how the container runs. The risk lies in the image you point at, so set it deliberately and only for images you have chosen and scan.

What should replace bitnamilegacy for PostgreSQL, Kafka and RabbitMQ?

For current versions, the official images with an operator: CloudNativePG, Strimzi and the RabbitMQ Cluster Operator. To keep the existing charts, or for versions past end of life, a maintained Bitnami-compatible image. See alternatives to the Bitnami PostgreSQL chart for the PostgreSQL options in detail.