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.
chuckadams 2 hours ago [-]
Broadcom gonna Broadcom. Don't anthropomorphize the lawnmower.
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 1 hours 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.
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.
EdwardDiego 27 minutes 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.
lapusta 2 hours 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 26 minutes 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 54 minutes ago [-]
I still see Gavin working on JEE.
_1tan 4 hours ago [-]
Are there any indications or just a feel?
bags43 4 hours 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 3 hours 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 3 hours 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 1 hours 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 3 hours 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.
58 minutes ago [-]
jcrben 1 hours ago [-]
What was the actual risk of using SpringBoot tho?
dpkirchner 2 hours ago [-]
Maybe this will finally break me of my habit of using helm charts, period.
skissane 1 hours 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
CBLT 4 minutes 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 constructs.
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 "advanced" 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.
bigstrat2003 1 hours 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.
ntqz 1 hours ago [-]
Grafana's Tanka is a very underappreciated tool if you have to do something similar to Helm.
cheshire_cat 2 hours ago [-]
Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.
chuckadams 2 hours 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 2 hours ago [-]
What are you planning on moving to ?
chuckadams 5 minutes ago [-]
Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.
bigstrat2003 2 hours 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.
EdwardDiego 30 minutes 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.
NewJazz 2 hours 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...
This is going to cause some disruptions. What are the alternatives out there to bitnami charts?
carrodher 2 hours 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 2 hours 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 2 hours ago [-]
My first thought was Linuxcontainers but I think they just maintain docker images, not helm charts
chrisandchris 2 hours ago [-]
They're all open source - fork the repo and start collectively maintain them.
gchamonlive 2 hours ago [-]
That doesn't really answer the question, does it?
jahsome 1 hours ago [-]
You asked for an alternative and that seems like an alternative to me.
gchamonlive 42 minutes ago [-]
It's not and I wasn't the one who asked
jahsome 20 minutes ago [-]
K
sbstp 12 minutes ago [-]
RabbitMQ next?
1 hours ago [-]
iotapi322 2 hours ago [-]
That's fine , their repmgr postgres repository was a joke.
remram 2 hours ago [-]
"Discontinuing this library of 120 things for everyone is fine, *I* didn't like *one of them* I won't say why"
js4ever 3 hours ago [-]
Great more enshitification! Broadcom is destroying everything they touch
jacquesm 3 hours ago [-]
That's nonsense. RPi would not exist if not for Broadcom.
wpm 50 minutes ago [-]
Yeah Broadcom had a load of unsellable SOCs they needed to off load
okanat 2 hours 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.
Rendered at 00:44:30 GMT+0000 (Coordinated Universal Time) with Vercel.
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
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.
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.
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.
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.
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 "advanced" 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.
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.
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.