Containers

Bitnami image removal from ECR Public

Starting on June 10th, 2026, Bitnami container images will no longer be available on Amazon ECR Public Gallery. If you currently pull Bitnami images directly from ECR Public in your workloads, you need to take action before this date to avoid service disruption.

In this post, we walk you through how to determine if you’re affected, how to mirror the images you need to your own private registry, and best practices for protecting your workloads from future upstream changes.

Background

Bitnami currently manages 317 container image repositories on the Amazon ECR Public Gallery, covering popular open-source applications and development stacks. Bitnami images will no longer be hosted or published on ECR Public after June 10th, 2026.

After the removal date, any image pull request to public.ecr.aws/bitnami/ will fail.

Am I affected?

You are affected if your workloads directly reference Bitnami images on ECR Public. Common places where this may occur includes:

To determine if you are impacted by Bitnami’s removal of their images from ECR Public, look for image URIs matching the following in your configurations, and deployment templates: public.ecr.aws/bitnami/

Understanding the impact

It’s important to understand how removal affects both running and new workloads:

Running containers with locally cached images will continue to operate normally until they need to re-pull the image for any reason. Any event that triggers a fresh image pull will fail. These events include:

  • A container crash or restart
  • A scaling event that launches new tasks or pods
  • A new build in your CI/CD pipeline
  • A rolling update or redeployment
  • Node replacement in your cluster

In production environments, these events happen frequently and often automatically. Without your action, your applications and build process that rely on Bitnami images in ECR Public will eventually fail.

How to mitigate impact

Step 1: Identify your affected workloads

Start by searching your infrastructure for references to public.ecr.aws/bitnami/:

# Search your local project files
grep -r "public.ecr.aws/bitnami/" .

# Search EKS/Kubernetes deployments
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | grep "public.ecr.aws/bitnami/"

# Search ECS task definitions
aws ecs list-task-definitions | xargs -I {} aws ecs describe-task-definition \
  --task-definition {} --query 'taskDefinition.containerDefinitions[].image' \
  --output text | grep "public.ecr.aws/bitnami/"

Step 2: Mirror images to Amazon ECR private repositories

Pull the images you depend on, and push them to your own private Amazon ECR repository:

# Authenticate to your private ECR registry
aws ecr get-login-password --region <region> | docker login --username AWS \
  --password-stdin <your-account-id>.dkr.ecr.<region>.amazonaws.com

# Create a repository
aws ecr create-repository --repository-name bitnami/<image-name>

# Pull, tag, and push
docker pull public.ecr.aws/bitnami/<image-name>:<tag>
docker tag public.ecr.aws/bitnami/<image-name>:<tag> \
  <your-account-id>.dkr.ecr.<region>.amazonaws.com/bitnami/<image-name>:<tag>
docker push <your-account-id>.dkr.ecr.<region>.amazonaws.com/bitnami/<image-name>:<tag>

For organizations managing many images, consider scripting this process:

#!/bin/bash
ACCOUNT_ID="<your-account-id>"
REGION="<region>"
IMAGES=("nginx" "postgresql" "redis" "mysql" "mongodb")

for IMAGE in "${IMAGES[@]}"; do
  aws ecr create-repository --repository-name bitnami/${IMAGE} --region ${REGION} 2>/dev/null
  docker pull public.ecr.aws/bitnami/${IMAGE}:latest
  docker tag public.ecr.aws/bitnami/${IMAGE}:latest \
    ${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com/bitnami/${IMAGE}:latest
  docker push ${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com/bitnami/${IMAGE}:latest
done

Step 3: Update your deployment configurations

Replace all references to public.ecr.aws/bitnami/ with your private registry URI:

# Before
image: public.ecr.aws/bitnami/nginx:latest

# After
image: <your-account-id>.dkr.ecr.<region>.amazonaws.com/bitnami/nginx:latest

Step 4: Validate

Deploy your updated configurations in a non-production environment first. Verify that:

  • Containers start successfully with the new image URI
  • Auto-scaling provisions new tasks/pods without errors
  • Your CI/CD pipeline completes end-to-end
  • Rollback procedures work as expected

Note: These steps should only be considered a temporary mitigation, given new no upstream Bitnami images will be published to ECR and your images will become out of date over time. We recommend you find alternatives for these containers images. In ECR Public today, you can look through Docker official images, Chainguard images, and Ubuntu images as alternative sources.

Best practices

We recommend adopting the following practices for all container workloads:

  1. Mirror production images to a registry you control. Never point production workloads directly at a public registry you don’t own.
  2. Implement pull-through caching. Configure ECR pull-through cache as a safety net for all public images your workloads consume. This works as a long term resiliency option. Given Bitnami’s removal is near term, we recommend directly and immediately mirroring all necessary Bitnami images before Bitnami’s stated removal date.
  3. Use image digests for production deployments. Reference images by SHA256 digest rather than mutable tags to ensure you always deploy exactly the image you tested.
 image: <your-account-id>.dkr.ecr.<region>.amazonaws.com/bitnami/nginx@sha256:abc123...
  1. Audit your image sources regularly. Periodically review your deployment configurations to identify dependencies on third-party public registries.

Recommended timeline

Identify affected workloads Immediately
Mirror critical production images Within 1 week
Update deployment configurations Before June 10th, 2026
Validate in non-production Before June 10th, 2026
Complete full migration Before June 10th, 2026

Conclusion

While the removal of Bitnami images from ECR Public requires action, it’s also an opportunity to adopt best practices around image management that will make your container workloads more resilient going forward. By mirroring images to your own private registry and implementing pull-through caching, you protect your applications from disruption regardless of changes to upstream public registries.

Start by identifying your affected workloads today, and begin mirroring your most critical images immediately.

Related Resources

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 above 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. 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=<your-account-id>.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.

Q: What about vulnerability patching and image updates after I mirror?

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 above) 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 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 or your AWS account team. For Bitnami-specific questions, you can open an issue on GitHub.

About the authors

Meg Sarros is a Senior Product Manager for Amazon ECR. She is based in New York City. In her spare time, she enjoys tennis and baking.