This article was originally published on the BackUpScale blog.
Why It Matters
For many open-source projects and small teams, Bitnami’s charts were the default starting point for running DBs and applications on Kubernetes. When a large vendor changes course, it sends ripples across the ecosystem; it can suddenly make basic infrastructure harder or more expensive to maintain. Drubernetes v2 ensures that Drupal deployments remain fully open, self-contained, and future-proof, regardless of corporate licensing shifts. Community-driven alternatives are essential to preserve innovation and accessibility.
Background: Why Drubernetes Needed a v2
When we first built Drubernetes, the goal was simple: make it easy for various organizations to deploy Drupal on Kubernetes using Terraform for infrastructure automation. Our stack relied heavily on community-maintained Helm charts (most notably Bitnami’s MariaDB chart) for reliability and ease of integration.
But the open-source ecosystem around Bitnami has shifted dramatically.
Bitnami’s Policy Shift: From Open Access to Paywall
Bitnami historically maintained one of the best collections of open Helm charts in the cloud-native space. These charts were widely used for MySQL, MariaDB, Redis, WordPress, and many others, often forming the foundation of production workloads for startups and open-source projects.
However, following VMware’s 2022 acquisition by Broadcom and its ensuing restructuring, Bitnami’s open chart repositories were deprecated, and support for their community versions effectively ended. As covered in Fastcode’s analysis, Broadcom’s pivot toward expensive subscription-only licensing has created a domino effect, shuttering long-standing open-source pipelines and forcing projects like ours to re-architect.
For open-source maintainers like BackUpScale, continuing to use Bitnami’s images now involves licensing uncertainty, limited updates, instability and the risk of losing upstream security fixes.
Simply put: Bitnami’s stack is no longer a viable base for sustainable open-source projects with limited funding.
What Changed in Drubernetes v2
To keep Drubernetes fully open and future-proof, we replaced our only Bitnami dependency, MariaDB, with the official MariaDB Enterprise Operator.
You can review the full changelog on the 2.0.0 release page and discussion in Issue #3.
Migration Guide: Upgrading from v1.x to v2.0
While this release represents a major step forward, the migration process does require manual intervention due to the difference in architectures.
Please review the complete details in the release notes.
Looking Ahead
Drubernetes v2 isn’t just about keeping up with upstream changes. It’s about reinforcing the open-source foundations we depend on. By moving to the official Helm charts, we gain:
- Transparent governance and roadmaps
- Consistent upstream support
- Easier compliance for enterprise users
- Freedom from vendor lock-in
We’ll continue to monitor the health of the operator ecosystem and ensure Drubernetes remains reliable, free from opaque licensing traps.
For more information, visit:
- The introducing article: Want to Run Drupal in Kubernetes? Try Our New Terraform Module
- The project page: gitlab.com/backupscale/drubernetes
- The Terraform registry module: BackUpScale/drupal/kubernetes