Changes to the Bitnami Image Catalog – Time to act now!
What is Bitnami?
Bitnami is a provider of pre-packaged software bundles containing popular applications such as WordPress, Joomla or GitLab, which can be easily installed on servers. Bitnami started in 2007 with the goal of delivering open source software as enterprise-ready solutions. After VMware acquired the company in 2019, this vision was further pursued: the catalogs continued to be actively maintained and regularly updated.
The provided packages are offered as so-called “stacks”, which include all necessary dependencies (e.g. databases, web servers). Bitnami supports various platforms such as local machines, virtual machines, containers (like Docker), and cloud services (e.g. AWS, Azure). The main goal is to simplify and standardize the setup and management of applications.
Bitnami is changing – what you need to know as an end user (TL;DR)
As of September 29, 2025, previous Bitnami images will no longer be available under the familiar image repository docker.io/bitnami. Instead, they will be moved to the new repository docker.io/bitnamilegacy and will no longer receive updates.
The commercial solution is now available under the name “Bitnami Secure Images (BSI)”. These images are hardened for security and continue to be maintained by Broadcom. They are also built with SBOM information and VEX data (Vulnerability Exploitability). In addition, commercial support for the corresponding Bitnami Helm Charts remains available.
Impact
After the cut-off date, Bitnami images will be available on a limited basis, and running applications can no longer be updated. The previous image repository docker.io/bitnami will be shut down. The previous images will be available in a legacy repository docker.io/bitnamilegacy, but these will no longer be updated. There will also be a paid repository docker.io/bitnamisecure.
If you do nothing and do not change the image repositories in your deployments to one of the two new image repositories, there is a high risk that ImagePullErrors will occur when the application restarts and images need to be pulled again.
To prevent this from happening in a productive environment, action must be taken.
Options:
The current community discussions show different perspectives: some still follow the open-source approach and rely on free availability and collaborative development. Others consider a paid service acceptable — provided the added value is reasonable.
Based on our experience and the information available to us, we see the following options:
- Bitnami Secure Images as a commercial solution – migration via Arrow.
- Commercial variant of BSI: Tanzu Application Catalog (TAC), part of Broadcom’s Tanzu portfolio. Licenses can be obtained through partners.
- Switch to another provider of hardened images (e.g. Chainguard–paid).
- Migrate to open source alternatives (with additional effort required).
Options in detail
Option 1
Option 1 offers a commercial solution through BSI, where a package of at least ten artifacts must be purchased. For organizations that regularly use Bitnami images and rely on their stability and security, this can be a worthwhile investment.
Customers with an active BSI subscription receive access to the full Debian repository – but without hardened images. Access to this repository is part of the subscription and comes with the first 10 licensed artifacts. These artifacts are instead based on Photon OS, are verified, hardened, production-ready, and regularly maintained by the vendor.
Important note:
Bitnami Secure Images are sold in packages of 10 artifacts each. This means that if you need 12 artifacts, you must purchase the package with 20.
Clarification: What exactly is an artifact?
Artifacts are essentially building blocks for developing, testing, and deploying applications. Here’s a summary of the most important points to help estimate how many artifacts you might need:
- An image is an artifact.
- A Helm chart is an artifact.
- A Helm chart that contains several subcharts (and therefore images) is an artifact.
- Two images running in production under two different tags count as two artifacts.
Option 2
Option 2 is another commercial variant, offered directly by Broadcom. The Tanzu Application Catalog is essentially a rebrand of Bitnami Secure Images.
What’s the difference? With TAC, customers do not get access to the Debian repository. However, after reaching the minimum number of 10 artefacts, additional licences can be purchased for individual artefacts. This provides more flexibility and emphasizes a security-first approach, since only hardened images are included in the catalog.
Question: Can I license 12 artifacts with Tanzu Application Catalog without having to purchase a package of 20? Answer: Yes!
Why is there no access to the Debian repository like with BSI? Because of the security-first approach. Broadcom focuses both on the further development and optimization of Photon OS and on guaranteeing near-zero CVEs with hardened images that are regularly maintained and updated. For customers with high security requirements, this is clearly a beneficial.
The last point we want to briefly address here has to do with the migration process. This is very minor for both BSI and TAC. The big advantage of options 1 and 2 is that you save yourself all the stress of migration. In practical terms, the following steps would be necessary:
1. Create a Secret (imagePullSecret):
kubectl create secret docker-registry regcred \
--docker-server=registry.vmware.com \
--docker-username=<dein Benutzername> \
--docker-password=<dein Zugriffstoken> \
--docker-email=<deine E-Mail>2. Deploy PostgreSQL with Helm and Secure Image:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-postgres bitnami/postgresql \
--set image.registry=registry.vmware.com \
--set image.repository=bitnami/postgresql \
--set image.tag=15.4.0-secure \
--set image.pullSecrets[0].name=regcred \
--set auth.postgresPassword=securePass123 \
--set primary.persistence.size=10GiOption 3
We’ve often been asked two questions: are there any other commercial solutions, and how do they compare to Bitnami/TAC?
One example is Chainguard. Chainguard positions itself as a lean alternative, delivering minimal, hardened images based on Wolfi, its own Linux distribution. Like BSI/TAC, Chainguard supports FIPS, STIG and FedRAMP, with a strong focus on critical infrastructure.
However, Chainguard does not fully replace Bitnami: Helm charts must be maintained separately or created by the user. In addition, the business model does not currently provide a clear economic advantage over Bitnami. Whether Chainguard could be a better alternative ultimately requires deeper evaluation and often depends on specific customer requirements.
Option 4
Open source alternatives are a free solution. However, their use should be carefully considered, as they can lead to increased effort and security risks.
Switching to open source alternatives definitely requires an individual migration plan for each application. Some applications are more difficult to switch than others. In any case, it is important to consider that the charts can vary greatly and that this can lead to increased maintenance costs. This is especially true if dependencies from other charts are used in the charts and the images may still be stored in different image registries. Security must not be overlooked, and it is important to keep in mind that not every image is hardened. As a result, you have to build hardening pipelines yourself. You also have to manage CVE scanning and the integration of additional SBOMs (Software Bill of Materials) and VEX (Vulnerability Exploitability Exchange) yourself. With the alternatives, you need your own security concept. This is certainly feasible if you have a team for this or if you set one up.
One point should not be ignored: what happens if one of the open-source alternatives also enters the commercial sector or the community abandons the project? This requires a risk analysis that takes such points into account.
What measures are required to implement the concept using the example of a Harbor Registry with external PostgreSQL?
1. The first step is to obtain an open-source version for Bitnami PostgreSQL. The “cloudnative-postgres-operator” can be used for this purpose. To do so, install the pg-operator in
helm repo add cnpg https://cloudnative-pg.github.io/charts
helm install cnpg cnpg/cloudnative-pg2. Once the operator has been installed, you can proceed with the deployment of a PostgreSQL instance via CRD. It is important to ensure that all databases, users, and roles are created correctly, as in Bitnami PostgreSQL. Otherwise, you may not be able to transfer the pq dump correctly.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: my-postgres
spec:
instances: 3
imageName: ghcr.io/cloudnative-pg/postgresql:15.4
storage:
size: 10Gi3. Depending on the procedure, the existing Harbor must be scaled down to maintain data consistency. And a dump must be transferred from the Bitnami instance to the new instance.
4. The alternative to Bitnami Harbor is goHarbor. This can also be installed with Helm.
helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor --untar5. Once the basic configurations have been changed in the values, a few more are needed to migrate from Bitnami Harbor to goHarbor. One example of how to continue using the PVCs would be to specify them as “existingClaims” in the goHarbor values. However, an InitContainer or manual intervention is also required to change the folders/files in, for example, the Registry PVC from 1001 to 1000 User and Group. This is because Bitnami uses user 1001 and goHarbor uses user 1000.
persistence:
enabled: true
persistentVolumeClaim:
registry:
existingClaim: "harbor-registry"6. Install goHarbor, check the configuration, and test whether images can be pushed and pulled. If everything is correct, the Bitnami instances can be removed.
In the case of Harbor, attention must be paid to the database and its users and roles, and the user for the files on the PVC are different. This example clearly shows that migration must be well planned, as there may be more work involved in other cases. This is because the file system of one Bitnami app may differ significantly from that of another.
Conclusion
Which solution is right for your specific scenario cannot be answered in general terms. The decision depends heavily on your technical circumstances and licensing requirements.
At evoila, we can help you to systematically assess your Bitnami usage and develop a joint strategy to ensure that your operations continue to run smoothly.
Official announcement: https://github.com/bitnami/containers/issues/83267
Relevant posts
API-driven Provisioning with Microsoft Entra and Azure Logic Apps
Back in August last year, Microsoft announced1 a new feature for their “Entra ID” Identity Management solution, called “API-driven inbound...
Instrumenting Spring Boot Apps with OpenTelemetry
In modern microservices architectures, observability is key to maintaining performance and reliability. OpenTelemetry (OTel) has emerged as the standard for distributed logs, tracing and...