I joined a new company this year and discovered that they've been putting off addressing how to manage Bitnami's recent decision to switch to paid images. After the person who hired me left, I'm left with the task of forming a strategy on how to tackle this change. I'd love to hear how others have approached this issue.
10 Answers
Honestly, your organization wasn't being careless; Bitnami's shift took a lot of people by surprise with less than a two-month notice. A good immediate step is to take the images you absolutely need and upload them to your own registry. This gives you some breathing room to either find or create alternatives.
They still offer legacy images if you need to use them, or you can always choose to build your own.
We prioritized the switch and ripped out the existing system. For instance, we replaced our Redis cluster chart in Kubernetes with a managed Redis solution from our cloud service provider in just three weeks.
We didn’t actually use any Bitnami products in the first place, so it didn’t impact us at all.
Just a heads-up, if you don’t have a relevant contribution to make, there’s no need to post.
We transitioned to CloudNativePG for Postgres, and it's been significantly better, especially when deployed on Kubernetes — you get reader replicas, automatic failovers, and S3 backups. Currently, we’re using it for non-critical databases, while other critical ones are on AWS RDS or BigQuery. It's been so beneficial that one of our devops team members even suggested moving the AWS databases to CloudNativePG to save around $5,000 each month. We're also exploring the Strimzi Kafka Operator for Kafka solutions.
I completed the migration to Strimzi for my team too — it’s been a great experience with a lot of built-in features. The only hurdle was shifting everyone from plaintext to scram512 since Strimzi doesn’t support plaintext. Overall, it was worth it, much easier and more secure than what we had before.
We switched to alternative images wherever we could. For those we can't move away from immediately, we’re using bitnamilegacy as a short-term solution and working towards finding better alternatives.
I suggest switching to bitnamilegacy to minimize any downtime while you migrate your infrastructure step by step. You'll have time to handle it properly instead of rushing things.
Bitnami has all the build receipts available, so you could build and maintain everything yourself from their upstream repositories. Keep in mind though that they’ve made many modifications to implement their own logic. Their helm charts and images usually work seamlessly for complex setups like Redis or Postgres clusters, but forking those chart repos means you'd take on long-term responsibility for maintaining them. So there’s really no perfect solution here.
True, while you can fork their charts, it can become a hassle to maintain your own versions. Our experience to fork was quite valuable, but it’s certainly not a switch that everyone might want to take.
I’m still using CentOS 7 for my projects, so I’ve stayed clear of this shift.
As soon as Broadcom acquired Bitnami, we decided to ban their use across our organization. Anyone who kept up with tech news likely anticipated that move.
Just to add, remember that Bitnami was acquired by VMware, which was then bought by Broadcom. If you weren’t aware of this shift, it might be worth reflecting on your team's radar regarding such industry changes.