public registries are not your supply-chain strategy

AWS warned that Bitnami images were leaving Amazon ECR Public.

Not a vulnerability with a scary logo.

Not a zero-day.

Not a dramatic cloud outage with a dashboard slowly turning red.

Just a registry change.

And that is exactly why it matters.

Starting June 10, 2026, Bitnami container images are no longer available from Amazon ECR Public Gallery. AWS said Bitnami had 317 container image repositories there, and any pull from public.ecr.aws/bitnami/ would fail after the removal. They even scheduled a 24-hour brownout on June 1 for the top 20 repositories so teams could notice the dependency before it became permanent.

That is a very practical, very boring kind of supply-chain incident.

The kind that does not need an attacker.

the container still running is not the problem

The part that tricks people is that running containers do not immediately explode when a registry changes.

If the image is already on the node, the process keeps running. The service looks fine. The dashboard is green. Everyone goes back to arguing about roadmap priorities.

Then something normal happens.

A pod restarts. An ECS task is replaced. A node gets recycled. The deployment rolls. CI builds a new artifact. Autoscaling adds capacity. Someone runs a disaster-recovery test. The image has to be pulled again.

And now your application is not really failing because of Kubernetes, ECS, Helm, Terraform, or your app code.

It is failing because a public shelf you treated like infrastructure stopped being your shelf.

That is the uncomfortable lesson here. Container availability is not only about your cluster. It is also about every registry, namespace, tag, mirror, chart, and pipeline reference that sits between source code and a running workload.

public images are still dependencies

We have a weird habit in engineering.

If a dependency is in package.json, we admit it is a dependency.

If it is in a base image, a Helm value, a Dockerfile, a CI action, or an old Terraform module, we often treat it like background weather.

It is not weather.

It is a dependency.

public.ecr.aws/bitnami/postgresql:15 is a dependency. So is bitnami/redis. So is the chart value that pulls it indirectly. So is the build image used by the pipeline that nobody has edited since the migration from Jenkins.

The reason this registry change is interesting is that it exposes how much of production still depends on informal distribution assumptions.

Somebody else hosts it.

Somebody else publishes it.

Somebody else keeps the namespace alive.

Somebody else decides when the business model changes.

That may be completely reasonable for a hobby project. For production, it needs to be a conscious decision, not an accident left behind by a copy-pasted tutorial.

mirroring is mitigation, not ownership

AWS gave the right immediate advice: find references to public.ecr.aws/bitnami/, mirror the images you need into your own private ECR registry, and update deployments to point at your registry.

Good.

Do that.

But do not confuse mirroring with solving the whole problem.

A mirror protects you from the immediate pull failure. It gives you a copy. It lets scaling, redeployments, and node replacement keep working after the upstream location disappears.

That is necessary.

It is not enough.

Once you mirror an image, you own a new question: who keeps it patched?

If the upstream source stops publishing to the place you used, your private copy can easily become a fossil with a nice AWS account ID in front of it. It will keep pulling. It may even make everyone feel safer. Meanwhile, the real update path is gone or moved somewhere else.

This is where teams get into trouble. They treat the mirror as a backup, but it slowly becomes the actual source of truth without the maintenance process that source of truth deserves.

A private registry is not a magic freezer where images stay safe forever.

It is inventory.

Inventory needs owners.

tags are not a recovery plan

The next trap is tag behavior.

A lot of teams still deploy images using loose tags because it is convenient. latest, minor-only tags, mutable chart defaults, whatever the tutorial suggested.

This is already risky when the registry is healthy.

During a removal event, it gets worse.

What exactly did you mirror? The tag name? The digest? The architecture variants? The chart dependency? The image used by the init container? The one in the backup job? The one in the dev namespace that production secretly depends on because environments are never as clean as diagrams?

If you cannot answer those questions, you do not have a supply-chain strategy.

You have hope with YAML.

The better practice is boring and slightly annoying:

• inventory image references across repos, charts, task definitions, Dockerfiles, and CI
• record the digests you actually run
• mirror the specific tags and digests needed for production
• update deployment config to your owned registry
• make future image updates an explicit workflow
• alert on direct pulls from public registries in production paths

That is not glamorous work. It is the work that prevents "why did the cluster stop scaling?" from becoming a registry archaeology exercise at 2 AM.

helm makes this easier to miss

Helm charts are a very common place for this problem to hide.

The application team installs a chart. The chart has image defaults. Maybe the defaults point to Bitnami. Maybe an environment override changes one image but not another. Maybe the chart pulls a sidecar or init container nobody remembers.

Six months later, the platform team asks, "Are we using public.ecr.aws/bitnami/ anywhere?"

Everyone searches the obvious repository and says no.

Then the brownout happens and a namespace quietly proves otherwise.

This is why registry policy cannot live only in human memory. The cluster should help. Admission control can reject unapproved registries. Image policy controllers can require known prefixes. CI can scan manifests before merge. SBOM and inventory tooling can tell you what is actually running, not only what the repo claims should be running.

None of that is perfect.

Perfect is not the point.

The point is to make hidden image dependencies boring enough to find before an upstream announcement finds them for you.

the platform team owns the paved path

This is not me saying every product team should become a container-registry specialist.

That is how you create twenty-seven slightly different solutions and one shared incident.

The platform team should provide the paved path:

• approved base images
• private registry namespaces
• mirroring and promotion workflows
• image signing and scanning
• digest pinning guidance
• pull-through cache rules where they actually fit
• alerts for public registry usage in production
• a clear exception process for teams that really need an external image

Then product teams can make real choices without memorizing every registry failure mode.

The key is to separate convenience from ownership.

It is fine to use public images. The ecosystem depends on that. The mistake is pretending public distribution is the same thing as production ownership.

Those are different things.

this is bigger than bitnami

Bitnami is just the visible example this week.

The broader pattern is older and much larger. Free tiers change. Public registries rate-limit. Namespaces move. Vendors retire channels. Images get renamed. Tags are deleted. Maintainers burn out. Companies acquire companies. Licensing changes. Security teams block a source. A registry outage happens on the day you need to replace nodes.

None of this is exotic.

It is normal software supply chain life.

Containers made packaging feel clean, but they did not remove the ownership problem. They just moved it into OCI layers, registry namespaces, tags, digests, chart defaults, cache behavior, and deployment controllers.

That is still better than the old world in many ways.

But better packaging does not mean free operational responsibility.

what i would do this week

If I owned a platform with Kubernetes or ECS workloads, I would not start with a heroic migration spreadsheet.

I would start with one sharp query:

Where do we reference public.ecr.aws/bitnami/?

Search repos. Search Helm values. Search Terraform and CloudFormation. Search task definitions. Search running workloads. Search CI.

Then I would split the results:

• production workloads that must be mirrored immediately
• build and CI images that can break releases
• development-only images that need a replacement but not a panic
• unused references that should be deleted

After that, I would mirror only what is actually needed, by digest where possible, and create a follow-up owner for the long-term migration path.

The important part is not only surviving June 10.

The important part is learning whether the organization can answer this kind of question quickly.

If it cannot, Bitnami is not the problem.

Visibility is the problem.

the punchline

The Bitnami removal from ECR Public is not dramatic because AWS gave notice, documented the impact, and described mitigation steps.

That is good.

But it is still a supply-chain fire drill.

It shows how easily a production system can depend on public image distribution without anyone treating that dependency as owned infrastructure.

Running containers are not enough. Cached images are not enough. A private mirror is not enough if nobody owns updates. A green dashboard is not enough if the next scale-out event cannot pull the image.

Public registries are useful.

They are not your supply-chain strategy.

Your strategy is the boring stuff around them: inventory, mirrors, digests, policy, owners, patch paths, and proof that the cluster is not quietly depending on someone else's shelf.

That is less exciting than another AI platform announcement.

It is also the kind of work that keeps production boring.

And boring production is still one of the best products engineering can ship.

references

• AWS Containers Blog: Bitnami image removal from ECR Public
• AWS Containers Roadmap: Bitnami image removal from ECR Public issue
• Broadcom Tanzu: Important update, transitioning Bitnami offerings on AWS

To test my projects, I use Railway. If you want $20 USD to get started, use this link.