[ECR Public] Bitnami image removal from ECR Public

Bitnami container images will no longer be available on ECR Public starting June 10, 2026. Bitnami currently manages 317 container image repositories on ECR Public, and will discontinue publishing and hosting their images on this registry. After this date, any image pull request to public.ecr.aws/bitnami/ will fail. You are affected if your workloads directly reference Bitnami images on ECR Public in Amazon ECS task definitions, Amazon EKS pod specifications, Helm charts, Dockerfiles, CI/CD pipelines, or infrastructure-as-code templates such as AWS CloudFormation or Terraform. To help users identify dependencies and raise awareness, a 24-hour brownout will occur on June 1, 2026 for the top 20 Bitnami container repositories on ECR Public. If your workloads are affected during this window, it indicates you have a dependency that needs to be migrated before the permanent removal on June 10th.

While your currently running containers will continue to operate normally using locally cached images, any event that triggers a fresh image pull after June 10, 2026 will fail. These events include container crashes or restarts, scaling events that launch new tasks or pods, new builds in your CI/CD pipeline, rolling updates or redeployments, and node replacements in your cluster. In production environments, these events happen frequently and often automatically. Without action, your applications and build processes that rely on Bitnami images from ECR Public will fail.

We recommend you take action before June 10, 2026 to avoid service disruption. First, identify affected workloads by searching your configurations for references to public.ecr.aws/bitnami/. Then, mirror the images you depend on to your own private Amazon ECR registry and update your deployment configurations to reference your private registry URI. Visit our blog post to learn more about how to mirror images and update your workloads [1]. Note that mirroring should be considered a temporary mitigation, as no new upstream Bitnami images will be published to ECR Public and your mirrored copies will become out of date over time. Given Bitnami's removal is near term, we recommend directly and immediately mirroring all necessary Bitnami images before the removal date rather than relying on ECR pull-through cache for this scenario. However, as a long-term best practice, we recommend configuring ECR pull-through cache as a resiliency option for all other public images your workloads consume [2].

If you have any questions or require assistance during this transition, please contact AWS Support [3].

[1] [Blog post: Mirroring Bitnami images to Amazon ECR Private](https://aws.amazon.com/blogs/containers/bitnami-image-removal-from-ecr-public/)
[2] [Amazon ECR Pull-Through Cache Documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html)
[3] [AWS Support](https://aws.amazon.com/support)

**Frequently Asked Questions**

**Q: Will my currently running containers stop immediately on the removal date?**
No. This only affects workloads whose deployment configurations (task definitions, pod specs, Helm charts, etc.) reference public.ecr.aws/bitnami/ image URIs directly. If your workloads already pull from a private registry, you are not affected.

For workloads that do reference ECR Public directly: once a container is running, it uses the image already stored on the host and does not maintain a live connection to the registry. Running containers will continue to operate normally. However, any event that triggers a new image pull from ECR Public, such as a container restart, scaling event, node replacement, or new deployment, will fail after the images are removed.

**Q: How do I know which Bitnami images my organization is using?**
Search your ECS task definitions, EKS/Kubernetes manifests, Helm charts, Dockerfiles, and CI/CD pipeline configurations for references to public.ecr.aws/bitnami/. See Step 1 in the linked blog for example commands.

**Q: Can I continue using Bitnami images after the removal?**
Yes. You can mirror the images you need to your own private Amazon ECR registry before the removal date. Once mirrored, you own the copy and can continue using them regardless of changes to the public source.

**Q: How much will it cost to host these images in my own private ECR registry?**
Amazon ECR pricing is based on storage and data transfer. For details, see [Amazon ECR Pricing](https://aws.amazon.com/ecr/pricing/). For most workloads, the cost of storing mirrored images is minimal.

**Q: I use Helm charts that reference Bitnami images on ECR Public. What should I do?**
You will need to override the image repository values in your Helm charts to point to your private registry. For example:

```
helm install my-release bitnami/nginx \
--set image.registry=.dkr.ecr..amazonaws.com \
--set image.repository=bitnami/nginx

```
Review your values.yaml files and update any hardcoded ECR Public references.

**Q: What if I'm using infrastructure-as-code (CloudFormation, Terraform, CDK)?**
Search your templates and code for public.ecr.aws/bitnami/ and update the image URIs to your private registry. Redeploy after making changes.

**Q: Will ECR pull-through cache continue to work after the images are removed?**
Pull-through cache only works if the upstream image is available at the time of the initial pull. If you have already pulled an image through the cache, that cached copy will remain in your private registry. However, new images or tags that were never cached will not be available after removal. We recommend proactively mirroring all images you need before the removal date.

**Q: Do I need to mirror every tag of every image?**
No. Identify the specific image tags your workloads use and mirror only those. Review your deployment configurations to determine which tags are in use. At minimum, mirror the tags currently running in production.

Once you mirror an image, you are responsible for keeping it up to date. Bitnami will no longer publish updates to ECR Public. You will need to establish a process for pulling updated images from an alternative source and pushing them to your private registry on an ongoing basis.

**Q: I have hundreds of workloads. Is there a way to automate this migration?**
Yes. You can script the mirroring process (see the example script in Step 2 in the linked blog) and use find-and-replace tooling or infrastructure-as-code updates to change image URIs across your configurations at scale. For large organizations, we recommend using [ECR replication](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html) to copy mirrored images across multiple regions if needed.

**Q: Who can I contact for help?**
If you need assistance, reach out to [AWS Support](https://aws.amazon.com/support/) or your AWS account team. For Bitnami-specific questions, you can open an issue on [GitHub](https://github.com/bitnami/charts/issues).

**Q: What is the June 1st brownout?**
On June 1, 2026, a 24-hour brownout will affect the top 20 Bitnami container repositories on ECR Public. This is designed to help you identify workloads that depend on Bitnami images before the permanent removal on June 10th. If your workloads are affected during the brownout, follow the mitigation steps above to mirror affected images and update your configurations.

Start with the linked AWS blog and search task definitions, pod specifications, Helm charts, Dockerfiles, CI/CD configurations, CloudFormation templates, and Terraform code for public.ecr.aws/bitnami/. Done means affected image references have been identified, required images mirrored to private Amazon ECR, and deployment configurations updated before the stated removal date.

Written by the indexing model from the issue text.