Bitnami Images Are Gone From ECR Public: How to Prevent Production Outages
If your container builds still pull from public.ecr.aws/bitnami, your Bitnami images are now running on borrowed time, and you may not find out until the worst possible moment. As of 10 June 2026, Bitnami container images are no longer hosted on the Amazon ECR Public Gallery. That was 317 repositories of popular open-source applications and stacks, covering things like nginx, PostgreSQL, Redis, MySQL, and MongoDB, that thousands of teams quietly depended on. The images are gone, and any pull request to that path now fails. The reason this is so easy to miss is that nothing breaks the instant the images disappear. Your running containers keep humming along on cached copies, and everything looks fine, right up until the moment something forces a fresh pull and a deployment, a scaling event, or a node replacement falls over.
The short answer is this. If you reference Bitnami images on ECR Public anywhere in your stack, you need to find every reference, mirror the images you still need into your own private Amazon ECR registry, and update your configurations to point at that private copy. The places to check are ECS task definitions, EKS pod specs, Helm charts, Dockerfiles, CI/CD pipelines, and any CloudFormation or Terraform templates. Search them all for the string public.ecr.aws/bitnami and treat every hit as a fault waiting to happen. Because the removal date has already passed, this is no longer a planning exercise. It is incident prevention, and the images you have not mirrored already cannot be pulled fresh.
Why a Quiet Registry Change Is a Loud Production Risk
The dangerous thing about this kind of break is the delay between the cause and the symptom. When a registry stops serving an image, the containers already running on your hosts do not care. They use the image already stored locally and hold no live connection to the registry. So your dashboards stay green and nobody raises the alarm. The failure is armed but not triggered. It waits for the next event that needs a clean pull of the image.
In a real production environment, those events are not rare and they are usually automatic. A container crashes and tries to restart. Traffic climbs and your autoscaler launches new tasks or pods. Your CI/CD pipeline kicks off a fresh build. You ship a routine release and the rolling update needs the image. A node gets replaced during routine cluster maintenance. Any one of these now hits a registry that returns nothing, and the task that should have started simply does not. The cruel part is the timing. The pull failure tends to surface exactly when you are scaling up under load or deploying a fix, which are the moments you can least afford a pipeline that will not move.
How to Find Out If You Are Exposed
Start with a blunt search across everything you own. In your project files, a recursive grep for public.ecr.aws/bitnami across your repositories will surface Dockerfiles, compose files, manifests, and IaC templates in one pass. For live Kubernetes workloads, you can list the images in use across all namespaces and filter for the Bitnami path, which catches anything running that your source control might not. For ECS, you can walk your task definitions and pull out the container image fields to check them the same way. The goal is a complete inventory of where the dependency hides, because the one reference you miss is the one that pages you at 2am.
Do not stop at your application repos. The reference often lives in less obvious places, such as a base image in a shared Dockerfile, a default value buried in a third party Helm chart, a build step in a GitHub Actions workflow, or a module in your Terraform that someone added two years ago. Helm is a particularly common trap, because the Bitnami chart ecosystem is widely used and the image registry is set through values that are easy to leave at their defaults. If you run any Bitnami packaged chart, check whether it is pointed at ECR Public and override the registry and repository values to your own copy.
Mirroring Is the Fix, and It Is Straightforward
The mitigation AWS recommends is simple in shape. Pull the images and tags you actually use, push them into a private Amazon ECR repository in your own account, and then update every reference to point at your registry URI instead of the public path. You authenticate Docker to your private ECR, create a repository, then pull, tag, and push each image. For a handful of images this is a few minutes of work. For a larger estate, you script it with a list of image names and a loop, and you use find and replace or an infrastructure as code change to swap the URIs across your configs at scale. You only need to mirror the specific tags your workloads use, not every tag of every image, so review your deployments and mirror what is actually in production at a minimum.
Once mirrored, validate before you trust it. Deploy the updated configuration to a non production environment first and confirm that containers start on the new URI, that autoscaling provisions new tasks or pods cleanly, that your pipeline runs end to end, and that your rollback path still works. The cost of keeping these images in your own private ECR is small, based on storage and data transfer, and for most workloads it is negligible against the price of a failed deploy during an incident.
Treat the Mirror as a Bridge, Not a Destination
Here is the part that is easy to get wrong. Mirroring stops the bleeding, but it does not solve the underlying problem, because Bitnami will not publish new images to ECR Public anymore. The copy you mirror is frozen in time. The moment you push it to your registry, you own its security posture, and every week that passes it drifts further out of date on patches and vulnerability fixes. A mirrored image you never update is a liability that quietly accumulates risk while looking perfectly healthy in your registry.
So plan the real migration alongside the emergency fix. AWS points to alternative sources already on ECR Public, including Docker official images, Chainguard images, and Ubuntu images, and for many common components one of these is a clean long term replacement. Whichever path you choose, the durable lesson is the one good operators already follow. Never point a production workload directly at a public registry you do not control. Mirror the images you depend on into a registry you own, and consider ECR pull through cache as a standing safety net for the public images you consume so a future upstream change cannot break you the same way. For the images that matter most, reference them by SHA256 digest rather than a mutable tag, so you always deploy exactly the image you tested, and audit your image sources on a regular cadence so a stray public dependency cannot creep back in unnoticed.
What to Do About It
If you have not started, start now, because the deadline is behind you and the only question left is whether an event has already exposed you. Spend the first hour building the inventory, searching every repo, cluster, and template for the Bitnami path. Within the first day, mirror the critical production images, the ones whose failure would take down a customer facing service or block a release. Then update your deployment configurations to the private URIs and validate in a non production environment before you let the changes flow to production. Treat anything still pointing at ECR Public as a live incident risk until it is fixed.
Once the fire is out, do the part that stops the next one. Pick proper replacements for the Bitnami images you were using, set up pull through caching for the public images you keep consuming, and add a recurring check to your process that flags any workload pointing at a public registry you do not own. The teams that come out of this stronger are the ones that treat a forced migration as the push they needed to take control of their container supply chain, rather than the bare minimum to get green again.
If your team is staring at a list of Bitnami references and is not sure which ones are load bearing, or you want a container supply chain that will not break the next time an upstream provider changes its mind, this is a good moment to bring in help. HAZERCLOUD works with founders and engineering leaders to harden AWS container platforms, from ECR mirroring and pull through caching to EKS and ECS resilience, so a registry change upstream never turns into your outage. Book a free consultation at https://hazercloud.com/contact/ and we will help you audit your image sources, mirror what matters, and put guardrails in place so this does not happen to you again.
