Hi, former cofounder of Bitnami here. I left VMware quite a while ago, so not involved with this. The technical team at Bitnami is still top notch and great people. I am quite baffled at this business decision.
burnt-resistor · 15m ago
I was a service provider of Zimbra and had great relations with VMware folks on Page Mill many moons ago. One my friends helped move VMware HQs within PA just out of college.
Fuck Wall St. greedy morons at Broadcom. Hubris will educate them the hard way as they fade in relevance.
remram · 3h ago
This announcement is a little hard to read. They make it seem that the current images under docker.io/bitnami/* get deleted on August 28? But individual chart READMEs seem to say that images will move during a period starting on August 28 and ending two weeks later? But looking at https://hub.docker.com/u/bitnamilegacy images have been copied already?
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
carrodher · 3h ago
The complete history of Bitnami container images has been copied to the "bitnamilegacy" repository. New tags will continue to be synced there until August 28th. After that date, "bitnamilegacy" will no longer receive updates, and images in the mainline "bitnami" repository will begin to be removed over a period that may take up to two weeks.
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
From the bottom of the post I know what they are hoping users will do:
> Suppose your deployed Helm chart is failing to pull images from docker.io/bitnami. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates.
They don't want to give instructions that are too helpful. They want your company CC to be the easiest way to fix the problem they created.
chuckadams · 4h ago
Broadcom gonna Broadcom. Don't anthropomorphize the lawnmower.
Maybe this will finally break me of my habit of using helm charts, period.
skissane · 3h ago
I’ve never used Helm charts. I learned K8S in a shop in which kustomize is the standard and helm is a permitted exception to the standard, but I just never felt any reason to learn helm. Am I missing out?
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
letmeinhere · 2h ago
Would you like to count the number of spaces that various items in your manifests are indented and then pass that as an argument to a structure-unaware text file templating engine? Would you like to discover your inevitable yaml file templating errors after submitting those manifests to the cluster? Then yes, you are really missing out!
CBLT · 2h ago
Helm gives you more than enough rope to hang yourself with. At $dayjob we barely use 3rd party helm charts, and when we do we eventually run into problems with clever code.
We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.
So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.
simmerup · 1h ago
The main advantage of helm in my experience is:
1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories.
2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config
bigstrat2003 · 3h ago
I wouldn't say you're missing out. If kustomize works for you, keep using it. I personally use helm because I cannot for the life of me wrap my head around kustomize. I've looked at tutorials, read the docs, and it just doesn't make sense to me. Helm, on the other hand, immediately clicked and I was able to pretty effortlessly write charts for our use. It's just a case of different preference in tools, imo.
cmckn · 2h ago
Kustomize feels like less of a hack to me, without the gotpl madness, but it’s way more painful to get something done in my experience. I’ve landed on just writing real code to craft the objects I want (using the actual types, not text), if I absolutely can’t get by with static manifests.
ntqz · 3h ago
Grafana's Tanka is a very underappreciated tool if you have to do something similar to Helm.
cheshire_cat · 4h ago
Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.
chuckadams · 4h ago
Write a few Helm charts and you'll understand why people want to stop using it. `nindent` will become a curse word in your vocabulary. It's a fine tool at the user level, but the DX is an atrocity.
cbzbc · 4h ago
What are you planning on moving to ?
dpkirchner · 1h ago
I'm using either opentofu(terraform) or plain yaml. I'm not a huge fan of HCL but at least it is structured and easily manipulated without worrying about whitespace.
chuckadams · 2h ago
Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.
theteapot · 2h ago
What's wrong with `kubectl apply -f xxx.yaml`?
physicles · 43m ago
We use kustomize because we have four environments that run basically the same stuff (dev with k3s, test, and two cloud regions). If we didn’t use kustomize, we’d be forced to reinvent it to avoid duplicating so much yaml.
bigstrat2003 · 4h ago
I mean, I have written a few (like 5-10?) and I don't understand either. I find that Helm is quite a nice tool which does its job very well.
NewJazz · 4h ago
Consuming one that is well written isn't too much pain, IME. But writing or modifying one can be really annoying. Aiui the values.yaml has no type schema, just vibes. The whole thing is powered off using text templating with yaml (a whitespace sensitive language), which is error prone and often hard to read. That's basically the main issues in a nutshell, it may not sound like much, but helm doesn't exactly do a whole lot and it does that limited set of stuff poorly.
Ah, I must have met some lazy charts then. Thanks for the correction. Still, it seems like that schema would end up a little inconvenient to integrate into your editor for writing the templates...
EdwardDiego · 2h ago
Golang string templating in a whitespace sensitive config language suuuuucks.
I might use Helm charts for initial deploys of operators, but that's about it.
Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.
On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
lapusta · 4h ago
Red Hat effectively killed their JBoss/Middleware team and the rest of it moved to IBM https://www.redhat.com/en/blog/evolving-our-middleware-strat... Quarkus and other tools were pushed to CommonHaus/Apache. I believe Vert.X was also mostly developer by RH team, although moved to Eclispe Foundation a decade ago.
Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.
I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
EdwardDiego · 2h ago
Yeah my old colleagues who work on Kroxylicious are now IBM. I keep asking them if they're wearing a blue tie to the office yet, they still don't think it's funny.
latchkey · 3h ago
I still see Gavin working on JEE.
EdwardDiego · 2h ago
I quite like Micronaut, especially the ability to use its compile time DI as a standalone library in a non-Micronaut app.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
_1tan · 6h ago
Are there any indications or just a feel?
bags43 · 5h ago
Company where I work had huge risk audit.
The second highest risk is using USA based cloud with 66/100.
The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.
jchmbrln · 5h ago
I’m completely out of the loop. What’s going on with Spring Boot?
Spring’s corporate steward is VMWare, and Broadcom bought VMWare, ergo Spring is subject to Broadcom’s whims.
loloquwowndueo · 5h ago
Not spring boot, but spring, is owned by VMware. Sure spring is under a free license but if upstream enshittifies, community forks would be required.
mindcrime · 3h ago
And as popular and widely used as Spring is, that would 100% happen. To me at least, I wouldn't count this as a particularly huge risk. But in an enterprise setting, with mandatory auditing and stuff, I can understand why there would be a requirement to at least pre-identify alternative(s).
xienze · 5h ago
Probably a bit of overreaction given that Broadcom is now in charge of Spring. At the end of the day it’s a wildly popular open source project — it has a path forward if Broadcom pulls shenanigans.
That said, I have noticed that the free support window for any given version is super short these days. I.e. if you’re not on top of constantly upgrading you’re looking at paid support if you want security patches.
jcrben · 3h ago
What was the actual risk of using SpringBoot tho?
ntqz · 1h ago
License changes - BSL or closing the source
If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes
Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL)
Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and individual developers not so much
somehnguy · 2h ago
What's the actual risk though? Just saying it's the riskiest at 77/100 doesn't mean anything.
moorow · 1h ago
Bitnami images have been problematic for a little while, especially given their core focus on security but still resulting in a CVE 9.4 in PgPool recently that ended up being used in the underlying infrastructure for a bunch of cloud hosts:
This is going to cause some disruptions. What are the alternatives out there to bitnami charts?
carrodher · 3h ago
The source code for Bitnami containers and Helm charts remains publicly available on GitHub and continues to be licensed under Apache 2.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
ethan_smith · 4h ago
Check out Artifact Hub, the CNCF-hosted charts from projects like Prometheus/Grafana, or the official k8s-at-home charts as solid alternatives to Bitnami.
gchamonlive · 4h ago
My first thought was Linuxcontainers but I think they just maintain docker images, not helm charts
chrisandchris · 4h ago
They're all open source - fork the repo and start collectively maintain them.
gchamonlive · 4h ago
That doesn't really answer the question, does it?
jahsome · 3h ago
You asked for an alternative and that seems like an alternative to me.
gchamonlive · 2h ago
It's not and I wasn't the one who asked
jahsome · 2h ago
K
sbstp · 2h ago
RabbitMQ next?
iotapi322 · 4h ago
That's fine , their repmgr postgres repository was a joke.
remram · 3h ago
"Discontinuing this library of 120 things for everyone is fine, *I* didn't like *one of them* I won't say why"
js4ever · 5h ago
Great more enshitification! Broadcom is destroying everything they touch
jacquesm · 5h ago
That's nonsense. RPi would not exist if not for Broadcom.
happycube · 20m ago
The current Broadcom (Avago) is literally not the Broadcom that RPi came from. Not that old-Broadcom was great, but...
okanat · 4h ago
RPi doesn't exist due to Broadcom. It exists despite Broadcom.
Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.
RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.
wpm · 3h ago
Yeah Broadcom had a load of unsellable SOCs they needed to off load
Fuck Wall St. greedy morons at Broadcom. Hubris will educate them the hard way as they fade in relevance.
From ticket https://github.com/bitnami/charts/issues/35164:
> Now – August 28th, 2025: Plan your migration: Update CI/CD pipelines, Helm repos, and image references
> August 28th, 2025: Legacy assets are archived in the Bitnami Legacy repository.
From README https://github.com/bitnami/charts/blob/4973fd08dd7e95398ddcc...:
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
- Bitnami: https://hub.docker.com/u/bitnami - Bitnami Legacy: https://hub.docker.com/u/bitnamilegacy - Bitnami Secure Images: https://hub.docker.com/u/bitnamisecure
From the bottom of the post I know what they are hoping users will do:
> Suppose your deployed Helm chart is failing to pull images from docker.io/bitnami. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates.
They don't want to give instructions that are too helpful. They want your company CC to be the easiest way to fix the problem they created.
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.
So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.
1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories. 2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config
I might use Helm charts for initial deploys of operators, but that's about it.
Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.
On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.
I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
The second highest risk is using USA based cloud with 66/100.
The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.
That said, I have noticed that the free support window for any given version is super short these days. I.e. if you’re not on top of constantly upgrading you’re looking at paid support if you want security patches.
If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes
Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL)
Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and individual developers not so much
[pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.
RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.