Bitnami recently updated its policy, restricting direct access to their secure container images (discussion here). This change impacts automated workflows, CI/CD pipelines, and production deployments that rely on Bitnami images and Helm charts.
To address this, the Bitnami Secure Hosting repository provides a workflow to rehost and tag secure images for stable, policy-compliant usage.
👉 Check it out on GitHub: bitnami-secure-hosting
🔍 The Problem
Bitnami’s new policy introduces:
“A focused set of more hardened, more secure images. These free images are intended for development and are only available on the latest tag. You can find them at bitnamisecure on Docker Hub
.”
This approach creates a major issue for developers and production teams:
- 🏷️ Only latest is available — you cannot select a specific version.
- 🔄 Reproducibility breaks — the same latest tag may change without notice.
- ⚠️ CI/CD pipelines become unstable, since updates may introduce unexpected changes.
- 🛑 Production systems lose reliability, because you can’t lock deployments to a tested version.
In practice, this makes the “focused, secure images” unstable and impractical for anyone who needs predictable builds, controlled upgrades, or long-term maintenance.
🎯 The Goal
The purpose of the repository bitnami-secure-hosting is to:
-
Reverse-engineer Bitnami
latesttag creation. - Tag each secure image with a specific version for better tracking.
- Enable controlled testing of each image before deployment.
This ensures that teams can continue using Bitnami images safely without relying on a moving latest tag, reducing production risks.
💡 The Solution
The Bitnami Secure Hosting repository solves these problems by:
-
Fetching the latest secure images from Bitnami's official secure registry (
docker.io/bitnamisecure). -
Inspecting and pinning each image to a specific product version using fields like
APP_VERSION. -
Rehosting images to a self-managed registry (
ghcr.io/vaggelisklsby default) for secure, predictable access. - Automating the workflow to ensure images remain up-to-date and safe for production.
This approach provides control, compliance, and reliability for teams that cannot rely on latest tags.
🚀 How It Works
- Pull images from the official Bitnami secure registry.
- Inspect images to determine the product version.
- Re-tag images according to their version.
- Push images to your self-managed registry for safe usage.
- Automated updates ensure the registry stays current without manual intervention.
✅ Conclusion – My Point of View
From my perspective, Bitnami’s new approach cannot be considered production-ready. Even their own documentation clarifies that the free, secure images are intended only for development use.
This policy shift feels like a setback for the open-source community. We’ve already seen similar moves from Docker, which introduced premium hardened images — raising the same concerns.
It makes me wonder:
- 🤔 Will official public images continue to be updated with the same frequency and security focus?
- Or will the priority shift toward paid solutions while the community versions stagnate?
The open-source ecosystem we’ve relied on for years is starting to change, and not always for the better.
While there are alternatives to Bitnami images themselves, the real impact is deeper:
- Kubernetes deployments
- Helm charts in production
- Automated CI/CD workflows
All of these depend heavily on predictable, versioned images. Without them, reproducibility and reliability suffer — especially at scale.
In short, this transition doesn’t just affect images, it creates long-term challenges for production-grade deployments in the open-source world.
Top comments (0)