Bitnami has switched the provision of its container images – including the popular Keycloak Image – to a largely fee-based model. For existing users of the free, well-maintained Bitnami images, this means significant changes. Keycloak users in particular now face significant security and operational risks if they continue to use old legacy images. Below, we highlight the key risks and present strategic alternatives, such as Keycloak as a Service or a Secured Keycloak Image, to ensure continued security and operation.
Risks and disadvantages of the Bitnami changes
1. Security vulnerabilities caused by legacy images
Bitnami now divides its images into two repositories: current, patched images are only available in the paid catalog, while the free legacy repository has been frozen. All older Keycloak versions have been moved to this legacy repository – and will no longer receive security updates.
For a security-critical application such as Keycloak (Identity & Access Management) this is fatal. Known vulnerabilities (CVEs) in the Keycloak server or its base (forexample Java, OS) remain unpatched. The result: A Keycloak server running on a legacy image may have open security vulnerabilities, which means a high risk of attacks, outages, or data compromise.
The compliance implications are equally problematic: operating software with known, unpatched vulnerabilities violates common security standards (e.g., ISO 27001) and audit requirements. Compliance violations and audit issues loom if companies continue to use insecure container images. To make a long story short: The security level of an unpatched Keycloak server drops dramatically, coupled with significant audit risks. Operating a Keycloak server with a legacy image in production is therefore practically a no-go.
2. Operational and stability risks (CI/CD issues)
In addition to safety issues, immediate operational problems arise. Many deployments reference fixed image versions in their Kubernetes Helm charts or CI/CD pipelines. – e.g. bitnami/keycloak:25.0.0. Due to the repository change such deployments now fail or unintentionally pull old images. In other words: Automated builds and updates suddenly break because the referenced image is no longer available at the expected path. In the worst case, this leads to service interruptions – for example, a failed Keycloak update can cripple the identity provider, preventing users from logging into connected applications.
In the free version Bitnami often only offers a :latest tag instead of versioned images. However, using :latest in production is a well-known anti-pattern: The version may change unexpectedly, which makes reproducibility and stability difficulty. You lose control over exact version statuses, which makes rollbacks or consistent testing nearly impossible.
There is a short-term emergency solution: In Helm Charts, you can manually change the image path from docker.io/bitnami/keycloak to docker.io/bitnamilegacy/keycloak to at least pull an image again. However, this only fixes the immediate error during image pull – The core problem remains: you continue to project an outdated, insecure image.
The bottom line is that operational risks arise on two levels:
- Current updates are made difficult or prevented, which can lead to possible downtime.
- Future deployments require workarounds (using legacy paths, etc.), but these are not a sustainable solution and run counter to best practices.
3. High internal costs and costs for alternatives
Organizations that wish to avoid the Bitnami subscription are faced with the necessity of migration. In practice, there are two main paths: (a) Switch to alternative images – such as the official Keycloak image/operator or community-maintained Helm charts – or (b) Building and maintaining your own keycloak container image. However, both approaches involve considerable effort.
Migration to alternatives: Switching to the official Keycloak Operator, for example, requires a significantly changed setup. The operator functions differently than the previous Helm chart, requiring concept adjustments and Kubernetes expertise. nötig sind. Alternative community helmet charts must also first be evaluated and adapted to your own environment. All this means a lot of initial migration work — from adapting the CI/CD pipeline to regression testing the new deployment method.
Self-maintenance of the image: The other way is to keep Keycloak up to date on your own.. In doing so, the company itself is taking on the role previously played by Bitnami—with everything that entails:
- Continuous CVE scanning: Regularly (e.g., weekly) check all container images in use for new vulnerabilities (use tools such as Trivy or Grype).
- Backporting patches: If a critical vulnerability occurs, e.g., in the base (such as the Linux library glibc)you have to incorporate your own update into the outdated image. This means writing a customized Dockerfile and building a new image that contains the fix.
- Keep the base system up to date: The Java runtime environment and other Keycloak dependencies also require ongoing maintenance to receive security updates.
- Intensive testing: Every self-built image must be tested extensively to ensure that your own changes do not cause side effects or errors in Keycloak.
This engineering effort is enormous and will remain so in the long term. Companies without a dedicated security engineering team quickly reach their limits here. Operational risk also increases, as errors during manual patching or testing can lead to instability.
Furthermore, switching to a “self-managed” Keycloak installation was exactly the scenario that Bitnami users originally wanted to avoid. One goes from being a passive consumer of a well-maintained image to an active manager of container security—a role that many had neither planned nor priced in. The costs for the necessary development time and increased susceptibility to errors can quickly exceed any savings. It is not without reason that commercial offerings such as Bitnami Secure Images cost five figures per year, which represents a significant, unplanned budgetary burden for smaller companies (either directly as subscription costs or indirectly as internal personnel resources).
Without professional updates, the only options are to professionalize your own software supply chain—an expensive undertaking—or switch to a solution with security support. Given the critical importance of identity systems, it is clear that in most cases it is not worth trying to implement the Bitnami change on your own.
Strategic alternatives: Operating Keycloak securely without additional effort
How can the risks mentioned above be avoided? Fortunately, there are ways out: instead of chasing patches on your own or taking out an expensive subscription, you can rely on professionally managed solutions. There are two approaches, depending on the needs of the company:
- Keycloak as a Service – a fully managed Keycloak instance operated by a specialized service provider (such as intension).
- Keycloak Secured Image – an expert-hardened and continuously updated Keycloak container image that runs in your own environment.
These alternatives relieve customers of the burden of updates and maintenance, and they do not have to worry about CVE management themselves. Below, we take a look at the advantages of these approaches.
Keycloak as a Service – Managed service instead of in-house operation
Keycloak as a Service (KCaaS) means that a complete Keycloak environment is provided as a managed service. Your company uses Keycloak without having to worry about installation, updates, or operational maintenance. A provider such as intension assumes responsibility for the security and availability of the Keycloak instance.
Key benefits at a glance:
- Ongoing security patches: The Keycloak servers are continuously patched by the provider—both for Keycloak itself and for the underlying system. Security vulnerabilities are closed as soon as updates are available, without you having to intervene. This means that there are no more unpatched CVEs in your environment.
- Stable, current environment: The service ensures that Keycloak always runs on a supported, up-to-date version. Nevertheless, updates are controlled and installed in a planned manner to ensure stability—no chaos due to suddenly changing :latest images.
- Lower operating costs: Your team will be relieved. There is no need to maintain your own CI/CD pipelines for Keycloak, build images, or analyze logs for security incidents. Maintenance costs are reduced to almost zero, allowing developers to concentrate on core tasks.
- Compliance & Support: A professional KaaS provider ensures that the Keycloak instance is operated in compliance with regulations (keywords: ISO certifications, data protection, etc.). In addition, support and expert knowledge are available, such as 24/7 monitoring or SLAs, which internal teams are often unable to provide.
- High availability: Operation on a robust, scalable infrastructure (e.g., multi-node Kubernetes, distributed zones) ensures a fail-safe Keycloak environment. Even peak loads or hardware failures are handled by the service, usually without any downtime—something that requires a lot of effort when operating in-house.
With Keycloak as a Service, you are choosing a strategic approach: instead of worrying about every security detail, you leave the platform to experienced IAM experts. This is an attractive option for companies that use Keycloak intensively but do not want to devote their resources to container security.
Keycloak Secured Image – Security for in-house operation
Some organizations want or need to continue operating Keycloak in their own data center/cluster. – whether for regulatory reasons or due to special integrations. There is also a solution for this case: The Keycloak Secured Image (e.g., offered by intension).
This model provides a hardened, secure container image of Keycloak that is updated regularly. The image is continuously maintained by the provider, similar to the Bitnami subscription model – without having to purchase the complete Bitnami package.
Features and benefits of Secured Image:
- Regular security updates: Micro-release updates are provided for all supported Keycloak versions as soon as critical security fixes become available. This means that even if you want to use a specific version (e.g., Keycloak 26.0.x), the provider will promptly send you an updated image with the latest patches. Security gaps are closed before they cause damage. Safety maintenance includes also the container’s host stack (operating system, Java, etc.) – not just Keycloak itself.
- Longer support cycles: Unlike pure open source upstream, which often only delivers patches in newer versions, a secured image guarantees a certain support period for each major/minor version.. For example, selected Keycloak versions will continue to receive updates for months or until the next but one version is released. This allows you to run relatively stable versions without having to jump on every new release immediately – and still remain secure.
- Easy integration: The secured image is made available via container registry and can be seamlessly integrated into your existing CI/CD pipeline. Instead of maintaining Dockerfiles yourself, you simply pull the image provided by the vendor – including all patches. This minimizes changes to your infrastructure.
- Support and expertise: If you use a commercially purchased Keycloak image, you will usually also receive support in case of problems. At intension, for example, you can get help if you have questions or incidents with the image, and benefit from the experience of the developers who build the images.
- No compromises when it comes to control: You retain full control over your Keycloak installation in your own environment—only image maintenance is performed externally. This is ideal if internal guidelines require in-house operation, but you still want to enjoy the convenience of guaranteed security.
With a secured image like this, you avoid the risk of running on insecure legacy systems without having to hand over your entire operation.. It represents a middle ground that combines security and independence.
Comparison: Self-hosted (legacy) vs. managed/secured Keycloak
Finally, we summarize the risks of using legacy systems and the advantages of a professional solution in a comparative overview:
| Risk associated with legacy images (in-house operation) | Advantages of managed service or secured image |
| Open security vulnerabilities: No new updates, known CVEs remain Analysis of Bitnami | Continuous patches: Vendor provides timely security updates, no open CVEs in the system. |
| Compliance violations: Operating with unpatched software jeopardizes audit and security standards | Compliance ensured: Thanks to up-to-date software and documentation (e.g., ISO certification/SBOM), operations are compliant and auditable. |
| Unstable deployments: Pipeline errors or downtime due to missing/old images | Reliable operation: Always available, tested images/services ensure smooth updates and high availability. |
| High maintenance costs: Constant scanning, patching (backports), and testing required | Minimal effort: Maintenance work is carried out by a specialized team – no need for in-house patch management |
| Unplanned costs: Either an expensive subscription or significant internal resources required | Predictable costs: Calculable pricing model for service/support; internal resources are conserved and can be used more productively. |
Table: Insecure legacy usage vs. professionally managed Keycloak solutions
Conclusion: Security and relief through modern Keycloak services
The switch to Bitnami Secure Images has highlighted how critical security maintenance is for Keycloak installations. Those who rely on free legacy images are taking a high risk—both technically and organizationally. But companies have a choice: instead of having to become “patch day heroes” themselves, they can fall back on professional Keycloak offerings.
Keycloak as a Service offers a comprehensive all-inclusive service that guarantees security, updates, and operation without your team having to invest time in infrastructure. Alternatively a Keycloak Secured Image ensures that you can continue to operate your Keycloak servers in-house, but always have an up-to-date, secure foundation beneath you. Both approaches help to strike a balance between security and effort.
Ultimately, a central IAM solution such as Keycloak should not pose an incalculable risk. With the right measures in place—whether that means changing your operating model or using hardened images—you can stay on the safe side and focus on what matters most: your applications and users. Feel free to contact us if you would like to learn more about secure Keycloak operation—we will help you find the optimal solution for your company.
