Topic starter
08/07/2026 7:09 pm
TL;DR: Bitnami’s move to a legacy image repository leaves Helm dependencies exposed to stale, unpatched container images unless users migrate to new open-source defaults or manage their own mirrored stack, according to PassBolt. The real issue is lifecycle control for dependent machine identities, not just chart maintenance.
Editorial analysis by NHI Mgmt Group, based on content published by PassBolt: “Bitnami Legacy Changes: Passbolt’s Migration Plan for Open-Source, Secure Helm Deployments”.
Key questions
Q: What breaks when a Helm chart depends on images that move to a legacy repository?
A: The immediate break is not installation, it is trust in the maintenance model.
Q: Why do legacy images create more risk for database and cache layers?
A: Database and cache services are stateful, so stale images affect persistence, session handling, recovery, and availability at the same time.
Q: What should teams do before replacing bundled Helm dependencies?
A: They should test the substitute components against the organisation’s availability, backup, restore, and secure configuration requirements.
Practitioner guidance
- Inventory chart dependencies and image sources Identify every Helm dependency that still points to Bitnami-managed images, then separate runtime-critical components from convenience defaults so you know what will break if the source becomes legacy.
- Assign owners for stateful service lifecycle Document who owns patching, backup, recovery, and upgrade decisions for MariaDB or MySQL and Redis-like services used by Passbolt, including any mirrored images you maintain yourself.
- Test the replacement stack before the default changes Validate MariaDB Operator and Valkey in a non-production environment against your availability, restore, and secure configuration requirements before treating them as the new baseline.
Bottom line: Bitnami’s repository changes turn a convenience dependency into a lifecycle and patching problem for Helm users.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:33 pm
Legacy image retirement is a lifecycle governance problem, not a packaging problem. When a chart still deploys but the referenced images no longer receive fixes, the security decision shifts from build-time convenience to runtime accountability. The issue is not whether the Helm chart is open source. The issue is whether the organisation can still govern patch exposure for the stateful dependencies that chart pulls in. Practitioners should treat upstream image retirement as a loss of assurance over the deployment chain.
A question worth separating out:
Q: How should organisations govern third-party images in Kubernetes?
A: Treat every referenced image as a governed dependency with an owner, a patch path, and a removal plan if upstream support changes. If the image source becomes legacy, the deployment model has already changed and the governance model must change with it.
👉 Read our full editorial: Bitnami legacy changes force a Passbolt Helm migration rethink