← Back to Blog
Header image for blog post: Bitnami deprecates free images: Migration steps and alternatives
Will Stewart
Published 18th August 2025

Bitnami deprecates free images: Migration steps and alternatives

📌 TL;DR

Bitnami is moving most container images to a legacy repository on August 28th, 2025, and stopping updates. If you're using Bitnami images or Bitnami helm charts, your deployments will break when they try to pull images that no longer exist.

This affects everyone using Bitnami charts, from weekend projects to production systems. Your pods won't start, your CI/CD will fail, and you'll be scrambling to fix it.

Here's how to fix it immediately and why migrating to Northflank makes more sense than dealing with Bitnami dependency hell.

What Bitnami is doing

Bitnami announced they're restructuring their container catalog.

Instead of maintaining the broad catalog of versioned images, they’re moving almost everything to a new bitnamilegacy repository that won’t receive updates.

This change is tied to Broadcom’s shift toward paid “Bitnami Secure” subscriptions, costing $50,000–$72,000 per year. Free users lose access to version-pinned images and regular security patches. In practice, that means teams relying on stable tags like postgresql:13.7.0 or redis:7.0.5 are left with two bad options: use the unsupported bitnamilegacy repo, or point to a latest tag in bitnamisecure (which is unsafe for production).

What is Bitnami?

What is Bitnami? They've been packaging open source software into containers and Bitnami helm charts for 18 years. Databases, web servers, caches, basically everything you need to run applications. Now Broadcom owns them and wants $50,000-$72,000 per year for what used to be free.

The changes:

  • Main docker.io/bitnami repository: Only "latest" tags for a few hardened images
  • Everything else moves to docker.io/bitnamilegacy with zero updates
  • Bitnami helm charts stop getting updates but the old ones stay published
  • Version pinning dies, no more postgresql:13.7.0, just latest or legacy

Your deployments will break

When Bitnami removes images from their main repository, any deployment trying to pull those images fails. This hits:

  • Production apps: Using Bitnami charts with version pinning break during pod restarts or scaling
  • CI/CD pipelines: Build processes fail when they can't pull Bitnami images
  • Dev environments: Local setups using Bitnami helm charts stop working
  • Any Kubernetes operation that needs to pull Bitnami images during maintenance

Quick fix: Update your image references

You need to update your Bitnami image references before August 28th or your stuff breaks.

Step 1: Point to legacy repository

For Bitnami helm charts, update the image repository to point to 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 using legacy, check if your app is available at https://hub.docker.com/u/bitnamisecure. Some applications get updated images there:

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

The secure repository only has latest tags and is for development use.

Step 3: Update all components

Most Bitnami helm charts have multiple images. Update everything:

# 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 deadline

# Test image pulls
docker pull bitnamilegacy/postgresql:13.7.0-debian-11-r9

# Validate helm chart
helm template my-release bitnami/postgresql -f updated-values.yaml

# Deploy to staging first
helm upgrade --install test-release bitnami/postgresql -f updated-values.yaml

Problems with legacy repository

This fix prevents immediate breakage but creates new problems:

  • No security updates: Images in bitnamilegacy never get patched
  • No bug fixes: Critical issues won't be fixed
  • Unknown lifespan: No guarantee legacy repo stays online
  • Version chaos: Teams end up on different incompatible versions

The best solution: Switch to Northflank

The quick fix above just kicks the can down the road. The real problem is depending on external image repositories that can disappear or change policies overnight.

Northflank eliminates this by providing managed services instead of making you manage Bitnami charts and container images.

How Northflank fixes this

1️⃣ Managed services instead of containers: Instead of deploying PostgreSQL through Bitnami helm charts, you get managed PostgreSQL. No images to manage, no updates to worry about.

2️⃣ Built-in service catalog: Need a database or cache? Get a managed service, not a container image that might disappear.

3️⃣ Automatic updates: Northflank handles security patches and updates. No more hunting for new Bitnami image versions.

4️⃣ No external dependencies: Your infrastructure doesn't break when Docker Hub "verified publishers" change their minds.

Examples

PostgreSQL:

Old way (Bitnami chart):

postgresql:
  image:
    repository: bitnamilegacy/postgresql
    tag: "13.7.0-debian-11-r9"
  auth:
    postgresPassword: "mypassword"
    database: "myapp"

Northflank way:

  • Create managed PostgreSQL addon in the UI
  • Get automatic backups, scaling, maintenance
  • Connection details injected as environment variables
  • Zero container management

Redis:

Old way (Bitnami chart with multiple containers):

redis:
  image:
    repository: bitnamilegacy/redis
    tag: "7.0.5-debian-11-r7"
  sentinel:
    enabled: true
    image:
      repository: bitnamilegacy/redis-sentinel

Northflank way:

  • High availability Redis cluster with built-in sentinel
  • Automatic failover and persistence
  • Monitoring included
  • No YAML, no containers

Development workflow benefits

Beyond solving the Bitnami migration problem:

  • Git deployment: Deploy from repos without managing Bitnami helm charts
  • Environment promotion: Move changes through environments without image registry issues
  • Built-in monitoring: No separate monitoring Bitnami charts to maintain
  • Reasonable pricing: Avoid Bitnami's $50,000-$72,000 annual fees

👉 Northflank’s take

Bitnami has provided huge value to the Kubernetes community for years. Their catalog of Bitnami helm charts and container images made deploying applications much easier. We understand open source needs sustainable business models, and charging for enterprise support makes sense.

But this deprecation is handled terribly. Removing images downloaded billions of times with 1.5 months notice is negligent. This should have been planned over years, not months.

CleanShot 2025-08-19 at 11.49.32@2x.png

Why this matters

  • Docker Hub "Verified Publisher" problem: When verified publishers can suddenly break critical infrastructure, it undermines trust in the entire ecosystem.
  • Left-pad redux: This is the npm left-pad incident but bigger. Bitnami images are foundational to much of the Kubernetes world.
  • Bad precedent: If Bitnami can break millions of deployments overnight, what stops other verified publishers from doing the same?
  • Community damage: Small teams and open source projects that used free Bitnami images face impossible choices: pay enterprise prices or scramble for alternatives.

This Bitnami migration crisis shows the weakness of depending on external parties for critical infrastructure. You need systems that don't break when someone changes their business model.

Use managed services: Instead of Bitnami helm charts for databases, use managed services with better reliability and performance

Integrated platforms: Platforms like Northflank provide complete solutions instead of assembling pieces from different vendors

Reduce external dependencies: Minimize reliance on external registries that can change policies without warning

Migration strategy

This Bitnami migration is a chance to build better infrastructure that won't break next time.

Phase 1: Stop the bleeding

Find all Bitnami usage:

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

# Check helm releases
helm list --all-namespaces

Update critical production deployments to use bitnamilegacy repositories.

Test everything before August 28th.

Phase 2: Strategic migration

For each Bitnami service, find managed alternatives:

  • Databases: PostgreSQL, MySQL, MongoDB → Northflank managed databases
  • Caching: Redis, Memcached → Northflank managed Redis
  • Message queues: RabbitMQ, Kafka → Northflank managed solutions

Start with non-critical environments.

Phase 3: Complete migration

Move production to Northflank managed services.

Eliminate Bitnami dependencies completely.

Document cost savings vs both maintaining Bitnami and paying for Bitnami Secure Images.

Conclusion

The August 28th Bitnami deadline forces a choice: apply band-aid fixes or build resilient infrastructure.

Updating Bitnami helm charts to use legacy repositories prevents immediate failures but doesn't fix the underlying problem. Legacy images get no security updates and might disappear entirely.

Northflank solves this by providing managed services instead of container dependencies. When the next "verified publisher" decides to monetize their free offerings, your infrastructure won't break.

What to do:

  • Fix immediately: Update critical deployments to legacy repositories before August 28th
  • Plan migration: Use this crisis to eliminate external dependencies
  • Choose reliability: Platforms like Northflank prevent future supply chain failures

Don't just patch the Bitnami problem. Fix the dependency risk entirely.

Start with Northflank today and build infrastructure that won't break when the next supplier changes their mind.

Share this article with your network
X