Bitnami conversion: What Keycloak users need to know and do now

What is changing in practice?

In mid-August, news startled the Kubernetes community: Broadcom will put large parts of the Bitnami catalog, which was previously available free of charge, behind a paywall. From August 29, 2025, many of the previously freely accessible container images and helmet charts can only be used as part of a paid subscription. Deployments based on the popular Bitnami images for Keycloak are particularly affected — and that's a great many. For years, Bitnami has been synonymous with simple, secure, and up-to-date deployments of open source applications in Kubernetes. Anyone who wanted to run Keycloak in a clustered environment often used the Bitnami Helm chart, as the official Keycloak project provides a Kubernetes operator, but no separate chart for classic installations. With the changeover, this self-evident concept is fundamentally changing. The older, versioned Bitnami images disappear from the known registry and are moved to a so-called “legacy repository.” It no longer receives security updates. In parallel, Broadcom is introducing the paid “Bitnami Secure Images.” These will continue to be maintained and hardened, but will only be available to paying customers. The Helm charts themselves remain open source and available on GitHub under the Apache 2.0 license. But by default, they point to images that are no longer accessible after the deadline without a valid subscription. This means that a “helm upgrade” can suddenly fail if the referenced images can no longer be downloaded. For operators of keycloak instances in Kubernetes, this is a serious risk, as failed deployments not only block development and test environments, but can also affect productive systems in the worst case.

Risks and practical consequences for companies

The risk that companies will stick with legacy images out of convenience or time pressure is even more serious. However, they are no longer provided with security updates, which can have fatal consequences for a safety-critical component such as Keycloak. After all, Keycloak manages sensitive identity and access data, and any unpatched vulnerability can become a gateway for attackers. In addition, many teams don't even know whether they are using Bitnami images directly or indirectly. Other charts — such as for PostgreSQL, which often serves as a backend for Keycloak — often move in Bitnami images transitively without operators being aware of this. The question of costs further aggravates the situation. Broadcom's pricing is clearly aimed at large enterprise customers who are willing to dig deep into their pockets for tested and hardened images. There are estimates of 50,000 US dollars per year and more in the community — sums that are barely manageable for smaller companies or open source projects.

Recommendations on how users should react

For Keycloak users, this means that they must act in the short term. First, an inventory is required to determine which images are currently being used and whether they come directly or indirectly from Bitnami. Anyone who provides clarity here can then decide specifically how to proceed. A short-term measure may be to mirror the currently used images from the legacy repository into a separate container registry. This ensures that deployments remain reproducible even after the changeover. However, this measure does not solve the problem of missing security updates, but simply postpone them. In the long term, there is no way around switching to alternative images. For Keycloak, the project's official container images are ideal. If you want to continue working with Helm charts, you can either fork the Bitnami chart and switch to other images or use alternatives, such as the chart maintained by Codecentric. A particularly future-proof option is to use the Keycloak operator, which is maintained by the community and automates many operational tasks. With the operator, Keycloak instances can be run directly on the basis of the official images without relying on Bitnami. Although switching to the operator requires some training, it offers clear advantages. Updates, scaling and backups can thus be implemented much more elegantly and the dependency on third-party providers decreases. In addition, operators can ensure that they retain control of the images used at all times and can harden or adjust them as required.

Conclusion: Why Bare.ID can be a strong alternative and support right now

The Bitnami transition makes it clear how dependent many organizations are on individual components in their software supply chain — often without even knowing it. Keycloak is and remains a powerful open-source solution for identity and access management. However, running your own business is complex and requires continuous attention. If you don't actively maintain the application, you risk security problems, unplanned costs, and outages. This is exactly where Bare.ID can play a decisive role. As a fully managed identity and access management platform based on Keycloak, Bare.ID assumes all operational responsibility — from deployment to security updates to scaling. Companies therefore no longer have to worry about container images, helmet charts or hardening the infrastructure, but can concentrate on their core processes. The operation is carried out on German cloud infrastructure, is GDPR-compliant and requires no dependence on individual image providers such as Bitnami. At a time when the framework conditions in the open source ecosystem can change so quickly, it is an advantage to rely on a solution that guarantees stability and security. The Bitnami switch should be a wake-up call for anyone who runs Keycloak themselves. If you act now, you can avoid failures and make your platform more independent and resilient in the long term. For many companies, now is the right time to check whether switching to a managed solution such as Bare.ID is not the better and more secure choice.