Bitnami Helm Chart Alternatives: What to Use in 2026

Key takeaways

1. Bitnami's public catalog was deleted on September 29, 2025, and the charts that remain at docker.io/bitnamicharts are no longer updated unless they reference Bitnami Secure Images components.
2. The free community tier publishes only latest, which rules it out for pipelines that depend on pinned, reproducible deploys.
3. A frozen chart freezes three things at once - image references, privilege defaults and configuration - so the risk compounds rather than sitting still.
4. Five options exist: stay, buy the commercial tier, move to upstream charts, move to a maintained hardened source such as Echo's charts, or fork and self-maintain. They differ mainly in who does the rebuilding.
5. Migrate chart by chart, pin by digest, and diff rendered manifests rather than values files - and ask every candidate source for a written remediation SLA before you commit.

Bitnami's OCI charts still live at docker.io/bitnamicharts, but they no longer receive updates unless they reference Bitnami Secure Images components. That means a chart you pull today pins image tags that will not be patched, so every cluster you deploy it to inherits a vulnerability backlog that only grows. The practical fix is to move to a chart source that rebuilds both the chart and its images on a published schedule.

What actually changed in the Bitnami catalog?

Bitnami announced a three-tier split of what used to be one free catalog. The dates and destinations are specific:

• August 28, 2025 - the public catalog became a limited community tier, and legacy assets were moved to docker.io/bitnamilegacy.
• September 29, 2025 - the public catalog at docker.io/bitnami was deleted. Brownouts ran on August 28, September 2 and September 17 ahead of it.
• Community tier today - a focused set of hardened images at docker.io/bitnamisecure, available only on the latest tag. No pinned versions.
• Charts - OCI charts stay at docker.io/bitnamicharts but stop receiving updates unless they use Bitnami Secure Images components.
• Bitnami Secure Images - the commercial tier, described as production-ready enterprise containers and charts with continuous security rebuilds, compliance artifacts and support.

A frozen chart is a supply chain problem, not a convenience problem

Teams often read this as a packaging annoyance. It isn't. A Helm chart is a deployment contract that carries image references, default privileges and configuration, and freezing it freezes all three.

• The images stop moving. A chart pinned to a versioned tag in the legacy registry will keep deploying that exact image build. New CVEs published against it are never remediated, because nothing rebuilds.
• The latest-only community tier breaks reproducibility. Pinning is the foundation of a repeatable deploy. A tier that only publishes latest forces you to choose between an unpinned deployment and a frozen one.
• The insecure defaults stay insecure. Community charts routinely ship with runAsRoot: true or privileged: true until someone overrides them, grant cluster-wide get, list, watch on all resources, and invite secrets into values.yaml. Our Helm chart hardening guide walks through each of those. Frozen charts mean those defaults never get corrected upstream either.

What are the real alternatives?

There are five honest options. They differ mostly in who does the rebuilding.

Echo publishes two shapes: first-party charts positioned as Bitnami replacements, and upstream charts with Echo's hardened images substituted in. Echo's container and library artifacts carry a 7-day SLA for critical and high CVEs, and the patched build is delivered without customer action (echo.ai, How automated patch SLAs reduce enterprise risk). If you are weighing the image layer separately from the chart layer, our Bitnami alternative migration guide covers the image side in detail.

How do you migrate without breaking deployments?

Work one chart at a time and keep the old release running until the new one passes.

1. Inventory what you actually use. helm list -A -o json across every cluster, then filter for bitnami in the chart name or repo. Most teams find fewer charts than they expect and more clusters than they expect.
2. Diff the values schema, not the values file. Replacement charts rarely use identical key paths. Render both with helm template and diff the resulting manifests - that catches renamed keys, changed defaults and dropped sub-charts in one pass.
3. Pin by digest, not by tag. Whatever source you land on, reference images by @sha256: in production. This is the single change that makes a repeat of the latest-only problem survivable.
4. Re-check the security defaults you inherited. Run the new chart's rendered manifests against your securityContext, RBAC and secrets policy before it reaches a cluster. Do not assume a "hardened" chart fixed the RBAC grant you were already overriding.
5. Cut over with a parallel release. Deploy under a new release name in a staging namespace, validate, then swap traffic. Uninstalling first turns a migration into an outage.

What to verify before you trust any replacement chart

Ask the same five questions of every candidate, including ours:

• What is the published rebuild cadence, and what is the remediation SLA by severity? A vendor that will not state one in writing does not have one.
• Are images referenced by digest in the shipped chart?
• Is there a signature or attestation you can verify at admission time?
• Is there an SBOM per image, regenerated per rebuild rather than per release?
• What are the chart's securityContext and RBAC defaults out of the box, before your overrides?

FAQ

Are Bitnami's Helm charts still available?

Yes. The OCI charts remain published at docker.io/bitnamicharts and can still be pulled. What changed is maintenance: Bitnami has stated those charts no longer receive updates unless they use Bitnami Secure Images components. The container images the charts referenced were moved to docker.io/bitnamilegacy, and the original public catalog at docker.io/bitnami was deleted on September 29, 2025.

What happened to docker.io/bitnami?

It was deleted on September 29, 2025, after the public catalog switched to a limited community tier on August 28, 2025. Existing images, including older and versioned tags, were relocated to the Bitnami Legacy repository, though images based on distributions deprecated more than three years ago were not copied across. Brownouts on August 28, September 2 and September 17 preceded the deletion.

Is the free Bitnami tier still usable in production?

It depends on whether you can live without version pinning. The community tier publishes a focused set of hardened images on the latest tag only, at docker.io/bitnamisecure. For most production pipelines that is disqualifying, because reproducible deploys and rollbacks both depend on pinned, immutable references. Teams that need pinning move to the commercial tier or to another maintained source.

Do I have to change my images and my charts at the same time?

No, and splitting the work usually goes better. The chart and the image are separate artifacts. A common path is to keep the chart structure you know, repoint image references to a maintained hardened source, verify, and only then evaluate whether to move the chart itself. That keeps the values-schema migration and the image migration as two reversible steps rather than one large one.

How do I stop this from happening again?

Treat every third-party chart as a dependency with an owner and an expiry. Record where each chart comes from, who rebuilds it, and on what cadence. Pin images by digest, verify signatures at admission, and keep an SBOM per image so you can answer "are we affected" without re-deriving your inventory each time a CVE lands.