Fix Broken Bitnami Deployments: Why Your Images Disappeared and How to Pull Them Again

What’s happening: “Image not found / Manifest not found / ImagePullBackOff” errors

You might have a setup where a Helm chart or Kubernetes manifest was deploying a Bitnami container image (e.g. bitnami/redis:6.x, or bitnami/postgresql:14.3) successfully in the past. Suddenly, you try the same deployment and you see errors like:

• manifest for docker.io/bitnami/redis:6.x not found
• ImagePullBackOff
• ErrImagePull
• “Image not found” in Kubernetes events.

In other words: the image that used to exist under docker.io/bitnami/... can no longer be pulled. Everything was working previously, but now it fails.

If you inspect GitHub Issue #35164, you can see that this is exactly the scenario many users reported: their previously working images no longer exist (or no longer exist at the expected registry path).

Why did this break? What’s Bitnami doing with its catalog?

To understand the fix, it helps to know the “why.” Bitnami is reorganizing how it publishes container images and Helm charts. Here are the key changes:

1. Deprecation / migration of public catalog
   Starting August 28, 2025, Bitnami began to move most existing container images from the docker.io/bitnami public catalog into a legacy archive repository called docker.io/bitnamilegacy.
   
   The legacy repository is meant for “fallback / migration” purposes only — it will not receive further updates, patches, or support.
   
   The public bitnami/ registry will continue to host a smaller, hardened set of images intended for development or community use (the “free community-tier subset”) or images aligned with Bitnami Secure Images.
   
   
2. Brownouts before full deletion / move
   Bitnami is doing “brownouts” (temporary unavailability) of selected images to raise awareness, gradually cutting over the catalog.
   They also delayed full deletion of the old public catalog until September 29th to give users more time to adapt.
   
   
3. Distinction between free community images vs enterprise/secure images
   The new structure encourages users to migrate to Bitnami Secure Images (which get support, updates, hardened base, etc.). The public (free) images, after the change, will be limited in versioning or only available under “latest” tags for a smaller set of applications.
   The legacy repository is explicitly marked as “no further updates or support” and is only intended as a transitional fallback.

In short: Bitnami is re-architecting its container image distribution, pulling many existing images out of bitnami/ and placing them in bitnamilegacy/ — which is causing your existing references (e.g. bitnami/mysql:8.x) to break.

The quick fix: switch to bitnamilegacy/imagename

If your deployment fails because docker.io/bitnami/<imagename>:<tag> no longer exists, the fastest workaround is:

• Replace references to bitnami/imagename with bitnamilegacy/imagename in your Helm chart values or Kubernetes manifests.
• For example, if you had:

you’d change it to:

• If using Helm with a setting such as image.repository, or global.image.repository, or perhaps a REPOSITORY_REFERENCE override (depending on chart structure), override it to bitnamilegacy/.... (The official docs in the issue even show commands like --set image.repository=bitnamilegacy/postgresql etc.)
• Then redeploy / helm upgrade, and Kubernetes will pull from the legacy registry path, restoring access to the archived image version.

This is a temporary workaround. Because the legacy images are not maintained, this should be seen as a stopgap while you plan a long-term migration.

What you should do longer term

Using bitnamilegacy/ is fine for now, but it’s not ideal forever. Here’s how to approach a more sustainable migration:

1. Audit what images you’re using
   Check which Bitnami images your workloads depend on, and whether they belong to the subset that remains in the “free community” (public) catalog after the change.
   
   
2. Migrate to Bitnami Secure Images where needed
   For production workloads needing supported, secure, updatable images, Bitnami recommends subscribing to their Secure Images offering. This gives you access to the full catalog (not just the limited community subset), patches, support, compliance artifacts, etc.
   
   
3. Update charts / CI / pipelines
   Change your Helm charts, values, manifests, CI/CD pipelines, image references, and any tooling so that they reference the “new” supported image locations (not legacy).
   Also, watch whether new versions of your images are published under the new catalogs or registries.
   
   
4. Test and validate
   Because some images in the legacy repository will not be updated, you may want to build your own images or use alternatives (official upstream, or images from other registries) especially if your version is out-of-date or unpatched.
   
   
5. Remove references to legacy when safe
   Once you have migrated everything to supported image sources, strip out all references to bitnamilegacy/ so that your stack is fully aligned with Bitnami’s intended new model.

Example: Helm upgrade with bitnamilegacy override

Here’s an excerpt from the issue showing how one might upgrade to the same chart version but override image repository paths:

In short: you keep the same chart, same tag, but override image paths to the legacy repository.

Why Bitnami is doing this (and what it means for users)

• Streamline catalog and reduce maintenance overhead
  Maintaining a huge catalog of images with many versions and patching them is costly. By moving many images into a legacy archive, Bitnami can better focus on a curated set of hardened, secure images.
  
  
• Push users toward supported image offerings
  The migration encourages users who need strong support or patching to opt into Bitnami Secure Images, where updates, security hardening, and enterprise features are available.
  
  
• Security, compliance, and build quality
  The new images are more hardened, have lower attack surfaces, and come with build artifacts (e.g. SBOMs, CVE transparency) under stricter quality processes (e.g. SLSA 3) per the announcement.
  
  
• Backwards compatibility via legacy
  The bitnamilegacy archive provides a safety net for users to migrate, but it’s clear this is not intended as a permanent solution.
  
  
• Encourage modernization
  Over time, users will need to adopt more modern images or shift to alternative registries or image providers, aligning their stacks with how Bitnami is evolving.