Bitnami BSI Change 2025: Your Helm Charts Broke. Your Deployment Broke. What Now?

A Quickfix and Long-Term Guide to Surviving the Bitnami Catalog Migration

Missed the deadline?
Then get ready for your deployments to start throwing lovely little tantrums with errors like ImagePullBackOff, ErrImagePull, or the classic image not found. Fun times, right?

This change comes straight from Broadcom’s shiny new “Bitnami Secure Images (BSI)” subscription model  and  a premium experience that’ll cost you somewhere between $50,000–$72,000 per year. If that doesn’t exactly spark joy, don’t worry: you’re in the right place. Welcome!

This blog won’t just explain what’s going on  and  we’ll also give you a quick fix (so you can still make it home for dinner tonight) and a long-term solution (so you don’t end up in the same mess again).

Starting August 28, 2025, the Bitnami change will quite literally pull the rug out from under our feet. Sure, there were warning signs earlier this year  and  small changes, hints, subtle nudges,  but many companies decided to… well… wait it out. Hope is not a strategy, but hey, maybe someone would eventually show up with a magic solution, right?

If you did notice the signs , like:

…and the deployment errors we mentioned above, then congrats! 🎉
Wait… but why are you still reading this blog? Either you don’t have any dependencies (lucky you), or you already solved the problem (even luckier you). Either way, we’re happy you’re here  and  especially if you end up sharing this with teams that haven’t slept in days and now twitch nervously every time the 1000th alert of the day pops up.

We’ve written about this shift before ,  but that was just the beginning. What’s next? Well… let’s just say the truth isn’t exactly going to be anyone’s favorite bedtime story.

Tough Changes — Tough Times

Thanks to Jan-Otto Kröpke and Northflank, the changes have been carefully summarized. Bitnami itself also managed to condense the impact into a handy one-pager  and  so you don’t have to spend hours digging through GitHub issues and comment threads. Let’s get straight to the facts:

1. Community Catalog (Free Tier)

• Goodbye Debian images: Starting August 28, 2025, no new Debian-based images will be provided in the community catalog.
• Hello “secure” only: Community users get a tiny, curated selection of hardened Bitnami Secure images.
• “latest” or nothing: These free images are only available as :latest. No more version tags (e.g. 10.6.0, 2.5.0).
• Intended use: Development and testing only  and  not for production.

Where to find them:

• New catalog: docker.io/bitnamisecure
• Source code and Helm charts remain under Apache-2.0 on GitHub.

2. Legacy Repository

• Migration of old images: All existing images (including older tags) will be moved to docker.io/bitnamilegacy.
• Frozen in time: These won’t get security patches, updates, or support.
• Purpose: A temporary crutch, so that old deployments don’t immediately explode. But you’re expected to drop it fast.

3. Bitnami Secure Images (Paid / Enterprise)

For production workloads, Broadcom is moving to a paid model called Bitnami Secure Images.

Features include:

• Hardened containers with smaller attack surfaces
• Continuous rebuilds with the latest security patches (SLSA Level 3)
• SBOMs, VEX/KEV transparency for compliance & CVE management
• Enterprise support & LTS (multiple stable release lines)
• Distroless images (tiny footprint, fewer packages, fewer attack vectors)
• Support for standards like DISA STIG, FIPS, FedRAMP
• Coverage: 280+ apps, 118+ Helm charts
• Distributed via Broadcom / Arrow Electronics

4. Timeline

• Until Aug 28, 2025: Deprecation notices show up in READMEs/docs. Time to fix your pipelines.

Aug 28, 2025:

• Community gets only the new “secure latest” subset.
• All older images are moved to the legacy repo.

After Aug 28, 2025:

• Community = only latest for dev/test
• Production = must migrate to paid Bitnami Secure Images

5. Practical Impact

If you’re a community user:

• Pipelines pointing to docker.io/bitnami/<app>:<version> will break, since version tags disappear.
• Workaround: Switch repo URL to docker.io/bitnamilegacy → but that’s insecure and unsupported.
• Long-term: Migrate to bitnamisecure (latest) or to the paid offering with versioned, supported images.

If you’re running production:

• You basically have to move to paid Bitnami Secure Images. Otherwise, no more patches, no more updates.
• That’s Broadcom’s/Bitnami’s plan… whatever.

It sounds scarier than it actually is. We’ll explain why later. For now: even if you missed the deadline and that’s why you’re reading this blog → stay calm.

6. Is this antisocial? No. Ugly? Yes.

The internet is fuming. Many accuse Bitnami or Broadcom of betraying the community. Only a few pause to acknowledge that Bitnami has provided an amazing free service for years  and  with hardened Helm charts and secure container images that powered countless production environments.

Don’t forget: For over 18 years, they’ve been packaging open-source software and first in VM installable formats and later into containers and Helm charts. Databases, web servers, caches  and  basically everything you need to run apps.

But nothing lasts forever. At some point, refinancing kicks in. We’ve seen this before, and we’ll see it again. Looking back at the last 2–3 years: the risk of free/Open Source products that are too good is always the same → if nobody buys the Enterprise tier, eventually there’s a license change or a paywall.

Is it nice? No.
Is it the end of the world? Also no.

So what does this mean for you? Keep a cool head. There’s a quick fix if you want to get things running again this afternoon.

Quick Fix: Update Your Image References

Big thanks to Northflank for their excellent blog  and  no need to reinvent the wheel. Let’s give credit where it’s due (and shamelessly recycle the example).

Bottom line: you need to update your Bitnami image references before August 28th, or things will break.

Step 1: Point to the Legacy Repository

For Bitnami Helm charts, update the image repository to use legacy:

# PostgreSQL example
postgresql:
  image:
    repository: bitnamilegacy/postgresql
    tag: "13.7.0-debian-11-r9"
    metrics:
        image:
          repository: bitnamilegacy/postgres-exporter
          tag: "0.10.1-debian-11-r52"
      volumePermissions:
        image:
          repository: bitnamilegacy/bitnami-shell
          tag: "11-debian-11-r27

Step 2: Check Bitnami Secure First

Before falling back to legacy, check whether your app is available at docker hub / bitnamisecure.

If it exists there, you can pull the “secure” version ,  but remember: dev-only, latest tags only.

# If available in bitnami secure (dev only, latest tags only)
postgresql:
  image:
    repository: bitnamisecure/postgresql
    tag: "latest"

Step 3: Update All Components

Most Bitnami Helm charts use multiple images. Don’t forget to update them all:

# Redis example with all components
redis:
  image:
    repository: bitnamilegacy/redis
    tag: "7.0.5-debian-11-r7"

  sentinel:
    image:
      repository: bitnamilegacy/redis-sentinel
      tag: "7.0.5-debian-11-r8"

  metrics:
    image:
      repository: bitnamilegacy/redis-exporter
      tag: "1.45.0-debian-11-r1"

  volumePermissions:
    image:
      repository: bitnamilegacy/bitnami-shell
      tag: "11-debian-11-r27"

Step 4: Test Before the Deadline → 💀

Well… too late. If you’re reading this after August 28th, it’s already over. ☠️

The Dark Side of the Legacy Repo 🌒

So yes ,  pointing everything to bitnamilegacy buys you some time. But let’s be honest: it’s more like duct-taping a leaking pipe. It holds… until it doesn’t.

Here’s what you’re signing up for:

• Frozen forever: no security updates, no bug fixes, no new builds. What you pull today is what you’ll be pulling in 2035.
• Version roulette: different teams, different tags, zero consistency. Good luck debugging that.
• Expiration unknown: nobody knows how long Broadcom will keep the repo alive. Could be years, could be weeks, could be “oops, it’s gone” on a random Tuesday.
• Future breakage guaranteed: even if things work now, you’ll likely hit
  ImagePullBackOff or ErrImagePull again when tags quietly vanish.

In other words: the legacy repo is less of a “solution” and more of a grace period. It’s there to keep your cluster from crashing today  and  not to carry you safely into the future.

Long Fix: Evaluate and Migrate Away

Sure, you could just fork all the Helm charts and mirror all the images yourself. But let’s be honest: if you didn’t manage to do that before, why would it magically be easier now? The effort is huge  and  you’ll need serious automation around testing, upgrades, and rebuilds.

Remember: Bitnami didn’t just slap Helm charts together and point to mirrored images. In many cases, they built custom base images, hardened them, and tweaked the charts to run extra jobs or configure things differently. That’s years of engineering effort that won’t be trivial to replicate.

That said, once you’ve survived the quick fix, you have some breathing room. Here’s how to start:

Step 1: Audit Your Dependencies

• Run helm repo list to see which Helm repos you’re actually pulling from.
• Use ArtifactHub to check which charts are Bitnami-based:

• Extract image references from your clusters:

helm template myrelease bitnami/<chartname> | grep "image:" 

kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | grep bitnami 

helm list --all-namespaces

• If you’re using imagePullSecrets, Docker Hub stats can also reveal how many Bitnami images you’ve been dragging into production.

Now you’ve got a list. Time to find alternatives.

Step 2: Explore Alternatives 

• Redis: Instead of Bitnami charts, look at the Helm Community charts or, if no actively maintained chart exists, consider using an Operator (e.g. Redis Operator).
• Other databases/services: PostgreSQL, MySQL, MongoDB often have community or vendor-backed charts/operators you can switch to.
• Managed services: Don’t forget the option to move up a level. Instead of maintaining your own database or message queue, you could switch to managed offerings from your cloud provider or other vendors:
  • Managed PostgreSQL, MySQL, MongoDB
  • Managed Redis or Memcached
  • Managed RabbitMQ or Kafka
    This reduces operational overhead and ensures someone else keeps things patched, upgraded, and highly available.
• Images that must be hardened: You don’t have to rely on Bitnami. Hardened images can be sourced from trusted vendors like Chainguard or Quay (though usually paid).
• Core services (DNS, ingress, policy, etc.): For things like External DNS, Cert-Manager, Argo CD, Ingress NGINX, Kyverno and  you can already switch directly to the upstream charts on GitHub. Many orgs have been doing this for years.

Step 3: Cost vs. Value

At our shop, Redis was the deal-breaker. Since most of our workloads weren’t tied to Bitnami, paying $50,000–$72,000/year didn’t make sense. But if one-third or more of your stack depends on Bitnami charts and images, then the paid subscription might be the most cost-effective way forward.

Step 4: What Actually Stays Free?

Not everything is disappearing:

• Sealed Secrets and minideb are unaffected.
• Those images will still live on docker.io/bitnami, since they belong to Bitnami Labs, not the commercial Bitnami offering.

So yes, it’s not all doom and gloom. Some tools remain free and open.

Takeaway

Migrating away isn’t trivial,  but it’s also not impossible. With a good audit, a strategy for alternatives, and maybe selectively paying for what you really need, you can reduce risk and avoid another round of 1000 nightly alerts.

Wrap up: 

Seriously ,  panicking never fixed a deployment. The easiest way out? Sure, just pay.
Pay what? Pay where? Pay how? → We covered what you need to know about the subscription model earlier in this blog.

But before you pull out the company credit card, take a step back and rethink your choices.

This whole Bitnami migration mess highlights one uncomfortable truth: if your infrastructure relies too heavily on someone else’s “free” offerings, you’re vulnerable the moment they change the rules.

What You Can Do Instead

• Use managed services where it makes sense: Instead of self-hosting every database or queue via Helm charts, consider cloud or vendor-managed offerings with guaranteed patches and uptime.
• Diversify dependencies: Don’t tie everything to a single registry or provider. Spread the risk.
• Audit your stack: Find out where you depend on Bitnami charts and images, and create a plan for alternatives (operators, upstream charts, hardened images from other sources, or building your own).
• Stay pragmatic: Sometimes paying is cheaper than rebuilding. Sometimes rebuilding gives you freedom in the long run. Both are valid paths  and  just make the choice consciously.

Beyond the Tech Side 

Don’t just think about the technical solution. Ask yourself:

• Licenses & Compliance: What changes if you switch to Bitnami Secure subscriptions? How does it affect audits, certifications, or procurement processes?
• As an end-user: Do I get the rights I need to run production safely, or am I locked into “latest-only” builds that create more risk?
• As a service provider: What contractual or compliance obligations do I take on if I depend on a paid Bitnami offering? Am I still free to deliver my services under the same SLAs?
• Future-proofing: If I buy in, what happens if the license terms change again in 2–3 years? Increase in prices?

These questions are just as critical as choosing the right image repository. 
We try to cover it in the Blog here:

The Choice After August 28th

• Band-aid fix: Point your charts to the legacy repo. Quick relief, but no patches, no updates, and no guarantees.
• Long-term resilience: Use this as a wake-up call to reduce single points of failure and build infrastructure that won’t collapse just because someone flipped their business model.

Also keep in mind that even when a vulnerability is fixed in an image, the fix often depends on the vulnerability being exposed and documented. The CVE database faced a funding crisis and the National Vulnerability Database (NVD) is currently struggling with a large backlog of unprocessed vulnerabilities, which can delay when crucial information like severity scores becomes available.

The future is exciting, but one challenge at a time!

Don’t just patch the Bitnami problem.
Fix the dependency problem — technically, legally, and strategically.

Further exciting topics:

• Are You Affected by Bitnami LTS and Docker Hub Pull Rate Limits?
• The Great Bitnami Shift: What the New Costs and Licenses Mean for End Users
• Interview: Broadcom macht Bitnami kostenpflichtig – wie reagiert Open Source?
• Die GNU-GPL (General Public License) – Wichtige Fakten im Überblick
• Bitnami deprecates free images: Migration steps and alternatives
• Argo CD: How to Use a private OCI Helm Chart Repository