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.
Is there a company more "Take what you can, give nothing back" than Broadcom? Probably not.
Broadcom's continued ability to perform well while only serving ever more upmarket areas, & cutting everyone else loose (& generally giving no figs) is fantastically impressive.
Broadcom is just private equity buying products to bleed dry. Nobody thinks VMware is the future, but the folks that use it are enterprises with deep pockets who are slow and reluctant to change so you can multiply the price by big numbers and get paid big while your dying acquired product meets its end.
VMware's lock on enterprise virtualization simultaneously made it essentially impossible for anyone else to compete like-for-like using a different platform and probably also doomed VMware's attempt to start pivoting to containers.
We were pretty successful moving to proxmox. They dont have the support some companies want but xcpng does. There are half decent options out there for corp use.
There are. I worked for a company that had a good KVM-based enterprise virtualization alternative with support. But they never had great commercial success with it displacing VMware. I understand they're having a lot more luck with a kubevirt-based option today post Broadcom acquisition of VMware.
If you have the resources to deal with kubevirt (read you are large enough for the increased efficiency across larger installations to overcome the higher cost of kubernetes labor) it's pretty decent. There are a shocking number of sub 5 location places out there that just need 2 low end boxes to virtualize active directory, tenable or equivalent scanner and a few other things that should be choosing xcpng or maybe proxmox if they are doing the analysis rationally (lol).
Java has a much stronger open source community with lots of corporate players. If Oracle tried to close the doors on it, everybody can pivot away in much shorter time than Vmware.
I don't exactly get what you mean by "Google torpedoed Sun".
Corporate players came into play after Oracle acquired Sun. The fear that Oracle would do the same as LibreOffice pushed players like IBM to have their own Java distributions.
Of course Oracle having more support for OpenJDK is not surprising. However, the open nature and existing players already make it easier to fork / replace Java compared to Vmware.
If Google actually cared about Java, they missed their opportunity to acquire Sun, own Java, do whatever they felt like doing with it for Android, and the rest of the industry, and best of all, they would never had to bother with any lawsuit.
Given how much the so called existing players contributed to save Java while Sun was going under, that is whishful thinking.
It’s mostly that they don’t understand their own users and potential customers in this particular case of Bitnami. There are so many other ways to increase revenue without alienating the core developer base. Enterprise want stability, breaking changes is a poor way to convince someone to pay you.
Last company was pretty heavy free user of Bitnami charts for various things but biggest being Redis clusters. I can't imagine they could convert everything into a cluster using their own charts before this kicks in. Very possible they end up tossing at least a year worth of licensing towards Bitnami.
Yes. Whatever money you get with this is going to be small and short-lived. The big money is in compliance. That is a GTM problem, not a technical one.
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.
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.
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.
> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.
Basically, I'll need to move to the regular upstream images for:
* web servers (Apache2 because it's well suited for my needs, but the same would apply to Nginx and Caddy)
* relational DBs (MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers; as well as PostgreSQL)
* key value stores (Redis)
* document stores (MongoDB)
* message queues (RabbitMQ and NATS)
* S3 compatible blob stores (MinIO and SeaweedFS)
* utility containers (like Trivy)
(either that, or I'll need to build them myself if the Dockerfiles remain available)
I'll stay away from Broadcom as much as possible.
Edit:
> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
I knew this would happen eventually. The images always looked nice, but were so hopelessly entangled in the Bitnami world there was no chance of forking them, or easily migrating away. Good thing I dodged that bullet… never trust a commercial vendor that trades you convenience for interoperability.
To me the images always looked overly complex, to the point where I frequently felt more at ease just doing an image from scratch myself. They never felt like a good fit for production systems.
I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image.
Stumbled upon issues when updating from an older MariaDB 10 release to MariaDB 11 when some Go software was trying to connect to it using a MySQL driver. Seems like people have similar issues with other stacks as well as well: https://bugs.mysql.com/bug.php?id=111697
I could just use MariaDB drivers where available, but honestly MySQL seems more popular and the MariaDB SPAC and layoffs soured my view of them; ofc PostgreSQL is also nice.
The removal (or moving) of the Bitnami images from Docker Hub is going to break a ton of systems that depend on them. I helped set up https://www.stablebuild.com/ some years ago to counter these types of issues, it provides (among other things) a transparent cache to Docker Hub which automatically caches image tags and makes them immutable - underlying tag might be deleted or modified, but you’ll get the exact same original image back.
This is exactly why so many of us have advocating for private registries and copies of every image you run in production. Pulling straight from Docker Hub was always a risk.
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
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!
A couple of years ago I was using https://kapitan.dev/ which I found really good at the time when using jsonnet files to generate the configs. I haven't used it for some time though.
I never understood why people didn’t serialize from JSON if they run a transformation step on the YAML anyway. Read JSON, alter in your favorite language, dump YAML as the last step, deploy. Instant prevention of a lot of sadness.
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.
We just set chart version equal to image version, they live in the same repo and are released and built together (and the chart is only published after successfully publishing the image, so it's always valid). The chart allows to override the image version but we almost never do that, it's for emergencies.
Replacing with hash is a neat idea, might start doing that too.
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.
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.
Every time I try to get into Kustomize, I feel it just has a documentation problem. It's written in Ph.D.ese without suitable examples
But, if it helps, my mental model of Kustomize is "it's a sequence of JSON Patch [1] operations"[2] which makes it absolutely stellar for mutating someone else's helm chart[3] (or yaml) since you can target anything for updating to your needs
My secondary complaint is that even JetBrains don't have good support for it, which makes working with them extra hard mode
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
One thing I haven't seen mentioned in comment. Dunno if Kustomize has something here. But: Helm is a shit but at least some kind of composition tool. Some way to have resource of various types associated to some top level idea.
Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.
Kustomize is nice but you’re missing out on objects lifecycle management.
Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
This doesn't happen for me, due to ArgoCD–the kustomize YAML is in a PR, and when it merges to the main branch, ArgoCD automatically deploys it. And yes I've found ArgoCD removes most objects when they are deleted from Git.
- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)
- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)
- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.
- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.
- Is composeable, has templates, etc.
So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.
Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.
> a plain helm install without any values rarely if ever gives you the deployment you need
works for me most of the time
> This is hardly unique to helm.
So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?
> In 2025 you should probably be using gitops
Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.
What do you mean by atomic deployment? There are no transactions in the Kubernetes API. Helm has to make one request for each object it creates or modifies, like any other client.
I believe(!) that the "rollback" that helm attempts to put back all the mutated objects, which it can - in theory - do because it maintains the previous state in the Secret objects that contain the rendered(?) and the values for the prior revision
try:
for obj in manifest_objects:
kubectl_apply(obj)
revisions.push(manifest_objects)
except:
old_revision = revisions.pop()
for obj in old_revision:
kubectl_apply(obj)
I work at Grafana, and Jsonnet powers our whole k8s infrastructure. It can get a little baroque sometimes but overall it’s tremendously powerful, and it’s fun to work with.
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.
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.
I used kustomize to build an ArgoCD install at a previous company, and I was impressed at how powerful it was. Our setup was pretty involved, and kustomize was able to handle all the per-environment differences easily, and the code was easy to work with.
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.
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...
There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer
> a little inconvenient to integrate into your editor for writing the templates...
Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
That is when you are writing the values when using the chart though, right? Yeah that's not too hard.
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
I don't exactly follow which part you're talking about, but yes JetBrains propagates the type and description from the JSON Schema into the golang templates inside the manifest files, same as it does with any type completion. They are reflected as their JSON Schema types, not golang's types, which I could imagine is potentially confusing to someone used to golang's view of the world but is for sure considerably better than "hurr, the type is whatever you say it is" which will be the case for values.yaml files without an accompanying .schema.json file
---
As for the "only string values for annotations," I think you mean patternProperties:
{
"$schema": "http://json-schema.org/draft-07/schema",
"type": "object",
"properties": {
"annotations": {
"type": "object",
"description": "this is the description of the annotations key itself",
"additionalProperties": false,
"patternProperties": {
"^[a-z][a-z0-9./]+$": {
"type": "string",
"description": "holds the value of the annotation"
}
}
}
}
}
and if I put the following, then the 123 gets flagged as a schema violation
annotations:
alpha: 123
as does
annotations:
_: xxx
0xcafebabe: denied
---
If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
I suggest checking out Anemos (https://github.com/ohayocorp/anemos), the new boy in the town. It is an open source single-binary tool written in Go and allows you to use JavaScript/TypeScript to define your manifests using templates, object oriented approach, and YAML node manipulation.
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.
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.
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.
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.
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).
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.
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
I think it would be more of a Redis situation - steward changes the license, someone large enough to maintain a fork creates one, and everyone moves to the fork. In Redis's case, Amazon forked it into Valkey.
Spring is so widely used that there are multiple "large enough" companies who could do this
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:
That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs.
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
I mean I understand that's the goal, but in this specific CVE it looks like the issue was introduced in Bitnami's own scripts sitting on top of everything, so a ideally-zero-CVE underlying OS isn't going to solve that problem at all.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
"Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license."
Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?
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.
What about the bitnami:minideb base image?
Or the stacksmith files necessary to build certain images?
Without access to these resources, it will not be possible to rebuild the images, will it?
Projects like Sealed Secrets and minideb remain unaffected by these changes. Container images for both projects will continue to be released on Docker Hub (docker.io/bitnami) as usual, without any modifications.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
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.
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.
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.
Is there a company more "Take what you can, give nothing back" than Broadcom? Probably not.
Broadcom's continued ability to perform well while only serving ever more upmarket areas, & cutting everyone else loose (& generally giving no figs) is fantastically impressive.
Broadcom is just private equity buying products to bleed dry. Nobody thinks VMware is the future, but the folks that use it are enterprises with deep pockets who are slow and reluctant to change so you can multiply the price by big numbers and get paid big while your dying acquired product meets its end.
VMware's lock on enterprise virtualization simultaneously made it essentially impossible for anyone else to compete like-for-like using a different platform and probably also doomed VMware's attempt to start pivoting to containers.
We were pretty successful moving to proxmox. They dont have the support some companies want but xcpng does. There are half decent options out there for corp use.
There are. I worked for a company that had a good KVM-based enterprise virtualization alternative with support. But they never had great commercial success with it displacing VMware. I understand they're having a lot more luck with a kubevirt-based option today post Broadcom acquisition of VMware.
If you have the resources to deal with kubevirt (read you are large enough for the increased efficiency across larger installations to overcome the higher cost of kubernetes labor) it's pretty decent. There are a shocking number of sub 5 location places out there that just need 2 low end boxes to virtualize active directory, tenable or equivalent scanner and a few other things that should be choosing xcpng or maybe proxmox if they are doing the analysis rationally (lol).
Oracle.
In fairness, Oracle keeps developing JVM and Java rather nicely, and keeps it open enough. I had expected worse.
Java has a much stronger open source community with lots of corporate players. If Oracle tried to close the doors on it, everybody can pivot away in much shorter time than Vmware.
Where were all those players when Google torpedoed Sun?
The large majority of work done in OpenJDK is by Oracle employees.
Had it been for most of those players, Java 6 would have been the last version.
I don't exactly get what you mean by "Google torpedoed Sun".
Corporate players came into play after Oracle acquired Sun. The fear that Oracle would do the same as LibreOffice pushed players like IBM to have their own Java distributions.
Of course Oracle having more support for OpenJDK is not surprising. However, the open nature and existing players already make it easier to fork / replace Java compared to Vmware.
Sun did not sue Google because they already lacked the money to do so.
What Google did with Android, it is hardly any different from Microsoft with J++, only that there the courts had another outcome.
Android with a Java subset and Kotlin, is hardly any different outcome than .NET with C#.
Corporate players came in, after money was available again, after the acquisition.
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&t=3462s
"James Gosling on Android and Java"
https://www.youtube.com/watch?v=IT__Nrr3PNI&t=6245s
If Google actually cared about Java, they missed their opportunity to acquire Sun, own Java, do whatever they felt like doing with it for Android, and the rest of the industry, and best of all, they would never had to bother with any lawsuit.
Given how much the so called existing players contributed to save Java while Sun was going under, that is whishful thinking.
nobody familiar with broadcom or how they are run should be even remotely surprised by this decision
It’s mostly that they don’t understand their own users and potential customers in this particular case of Bitnami. There are so many other ways to increase revenue without alienating the core developer base. Enterprise want stability, breaking changes is a poor way to convince someone to pay you.
Is there other ways that are just as easy?
Last company was pretty heavy free user of Bitnami charts for various things but biggest being Redis clusters. I can't imagine they could convert everything into a cluster using their own charts before this kicks in. Very possible they end up tossing at least a year worth of licensing towards Bitnami.
Yes. Whatever money you get with this is going to be small and short-lived. The big money is in compliance. That is a GTM problem, not a technical one.
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.
I take daily walks, and sometimes walk that campus. It always baffled me that it was bigger than my home town.
All gone now. Sad.
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?
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?
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.
- Bitnami: https://hub.docker.com/u/bitnami - Bitnami Legacy: https://hub.docker.com/u/bitnamilegacy - Bitnami Secure Images: https://hub.docker.com/u/bitnamisecure
> What are users expected to do exactly?
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.
Looks like it's $5k/month, minimum 12 months for "secure" images.
https://aws.amazon.com/marketplace/pp/prodview-pwqgz3mnvxvok...
You can always follow the "contact sales" form and see if they give you a higher or lower number than that.
> Legacy repository migration
> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.
Basically, I'll need to move to the regular upstream images for:
(either that, or I'll need to build them myself if the Dockerfiles remain available)I'll stay away from Broadcom as much as possible.
Edit:
> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
Hmmm: https://github.com/bitnami/containers/tree/main/bitnami/mari... and https://github.com/bitnami/containers/commit/7651d48119a1f3f...
I knew this would happen eventually. The images always looked nice, but were so hopelessly entangled in the Bitnami world there was no chance of forking them, or easily migrating away. Good thing I dodged that bullet… never trust a commercial vendor that trades you convenience for interoperability.
To me the images always looked overly complex, to the point where I frequently felt more at ease just doing an image from scratch myself. They never felt like a good fit for production systems.
I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image.
This did feel inevitable.
[dead]
> MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers
Could you tell more?
Stumbled upon issues when updating from an older MariaDB 10 release to MariaDB 11 when some Go software was trying to connect to it using a MySQL driver. Seems like people have similar issues with other stacks as well as well: https://bugs.mysql.com/bug.php?id=111697
I could just use MariaDB drivers where available, but honestly MySQL seems more popular and the MariaDB SPAC and layoffs soured my view of them; ofc PostgreSQL is also nice.
Broadcom gonna Broadcom. Don't anthropomorphize the lawnmower.
The source of this great quote, from the wonderful Bryan Cantrell: https://youtu.be/-zRN7XLCRhc
Said about Larry Ellison (who recently gave $6B to his son to buy CBS, and likely turn it into another ultra-wealthy right-wing mouthpiece rag).
But damn oh damn does Broadcom feel like a good fit for this statement.
38:28 https://m.youtube.com/watch?v=-zRN7XLCRhc&t=2308s&pp=0gcJCTA...
The removal (or moving) of the Bitnami images from Docker Hub is going to break a ton of systems that depend on them. I helped set up https://www.stablebuild.com/ some years ago to counter these types of issues, it provides (among other things) a transparent cache to Docker Hub which automatically caches image tags and makes them immutable - underlying tag might be deleted or modified, but you’ll get the exact same original image back.
That's what the announcement said, there is a copy of everything at https://hub.docker.com/u/bitnamilegacy
Still gonna break everyone’s CI until they manually update the tag. (And who guarantees that these tags will stay alive after they pull this)
This is exactly why so many of us have advocating for private registries and copies of every image you run in production. Pulling straight from Docker Hub was always a risk.
Maybe this will finally break me of my habit of using helm charts, period.
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
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!
A couple of years ago I was using https://kapitan.dev/ which I found really good at the time when using jsonnet files to generate the configs. I haven't used it for some time though.
I really, really, wish we could move away from yaml for tools like this.
If YAML is a foot-gun, templated YAML is a face-cannon.
I never understood why people didn’t serialize from JSON if they run a transformation step on the YAML anyway. Read JSON, alter in your favorite language, dump YAML as the last step, deploy. Instant prevention of a lot of sadness.
Yet somehow, all we have is YAML templating?
Kubectl will handle JSON without converting it to YAML. So if you are doing this, then just do kubectl apply -f deployment.json
CDK8s works really well. I'm sad it hasn't really taken off.
https://cdk8s.io/
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.
We just set chart version equal to image version, they live in the same repo and are released and built together (and the chart is only published after successfully publishing the image, so it's always valid). The chart allows to override the image version but we almost never do that, it's for emergencies.
Replacing with hash is a neat idea, might start doing that too.
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.
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.
Every time I try to get into Kustomize, I feel it just has a documentation problem. It's written in Ph.D.ese without suitable examples
But, if it helps, my mental model of Kustomize is "it's a sequence of JSON Patch [1] operations"[2] which makes it absolutely stellar for mutating someone else's helm chart[3] (or yaml) since you can target anything for updating to your needs
My secondary complaint is that even JetBrains don't have good support for it, which makes working with them extra hard mode
1: https://www.rfc-editor.org/rfc/rfc6902.html
2: it's a very "functional programming language" mental model https://kubectl.docs.kubernetes.io/references/kustomize/kust...
3: https://kubectl.docs.kubernetes.io/references/kustomize/buil...
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
One thing I haven't seen mentioned in comment. Dunno if Kustomize has something here. But: Helm is a shit but at least some kind of composition tool. Some way to have resource of various types associated to some top level idea.
Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.
Kustomize is nice but you’re missing out on objects lifecycle management.
Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
If you use the kustomize controller from the FluxCD project, you can set it to prune unmanaged objects.
In true GitOps, I think it's should be default on.
This doesn't happen for me, due to ArgoCD–the kustomize YAML is in a PR, and when it merges to the main branch, ArgoCD automatically deploys it. And yes I've found ArgoCD removes most objects when they are deleted from Git.
Some people like that Helm:
- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)
- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)
- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.
- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.
- Is composeable, has templates, etc.
So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.
Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.
> zero to fully running (...) in 5 seconds by just running helm install
Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.
> rollback on failure
This is hardly unique to helm.
> history metadata without (...) some external system
In 2025 you should probably be using gitops anyways, in which case the git repo is your history.
> a plain helm install without any values rarely if ever gives you the deployment you need
works for me most of the time
> This is hardly unique to helm.
So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?
> In 2025 you should probably be using gitops
Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.
> Gitops is literally just...
Please check https://opengitops.dev/
What do you mean by atomic deployment? There are no transactions in the Kubernetes API. Helm has to make one request for each object it creates or modifies, like any other client.
It's a misnomer, but I don't think OP invented that language, it's the word Helm uses for that flag: https://helm.sh/docs/helm/helm_install/#:~:text=the%20instal...
I believe(!) that the "rollback" that helm attempts to put back all the mutated objects, which it can - in theory - do because it maintains the previous state in the Secret objects that contain the rendered(?) and the values for the prior revision
type dealGrafana's Tanka is a very underappreciated tool if you have to do something similar to Helm.
I work at Grafana, and Jsonnet powers our whole k8s infrastructure. It can get a little baroque sometimes but overall it’s tremendously powerful, and it’s fun to work with.
Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.
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.
What are you planning on moving to ?
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.
Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.
I used kustomize to build an ArgoCD install at a previous company, and I was impressed at how powerful it was. Our setup was pretty involved, and kustomize was able to handle all the per-environment differences easily, and the code was easy to work with.
What's wrong with `kubectl apply -f xxx.yaml`?
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.
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.
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.
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.
I share your dislike of Helm, but FYI there are schemas for values, see for example https://github.com/bitnami/charts/blob/main/bitnami/postgres... and docs https://helm.sh/docs/topics/charts/#schema-files
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...
Oh, yeah, but who can blame them because writing JSON Schema files by hand is some onoz
Ironically (in the context of this submission) Bitnami has a "--schema" option to their README generator, which is why so many of their charts ship with .schema.json files: https://github.com/bitnami/readme-generator-for-helm/tree/2....
There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer
While digging up that link, I also spotted the tag line in their GitHub org which is hilarious https://github.com/bitnami#:~:text=trusted%20by%20ops
> a little inconvenient to integrate into your editor for writing the templates...
Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
That is when you are writing the values when using the chart though, right? Yeah that's not too hard.
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
I don't exactly follow which part you're talking about, but yes JetBrains propagates the type and description from the JSON Schema into the golang templates inside the manifest files, same as it does with any type completion. They are reflected as their JSON Schema types, not golang's types, which I could imagine is potentially confusing to someone used to golang's view of the world but is for sure considerably better than "hurr, the type is whatever you say it is" which will be the case for values.yaml files without an accompanying .schema.json file
---
As for the "only string values for annotations," I think you mean patternProperties:
and if I put the following, then the 123 gets flagged as a schema violation as does ---If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
Oh, OK. I didn't realize it made them visible in the golang templates.
I will leave it to others: https://noyaml.com
I suggest checking out Anemos (https://github.com/ohayocorp/anemos), the new boy in the town. It is an open source single-binary tool written in Go and allows you to use JavaScript/TypeScript to define your manifests using templates, object oriented approach, and YAML node manipulation.
You can read a comparison with Helm here: https://www.ohayocorp.com/anemos/docs/comparison/helm
P.S. I am the author of the tool.
I could see the writing on the wall with this.
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.
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.
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.
I still see Gavin working on JEE.
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.
Are there any indications or just a feel?
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.
I’m completely out of the loop. What’s going on with Spring Boot?
The VMware apocalypse.
One does not need VMware for SpringBoot so?
Spring’s corporate steward is VMWare, and Broadcom bought VMWare, ergo Spring is subject to Broadcom’s whims.
VMware owns Spring Boot https://en.m.wikipedia.org/wiki/Spring_Boot
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.
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).
> Not spring boot, but spring, is owned by VMware
How do I reconcile this statement with VMWare holding the copyright which you will find unambiguously littered in the official Spring Boot repository?
Since you contend the contrary, who does in fact hold the copyright?
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.
What was the actual risk of using SpringBoot tho?
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
I think it would be more of a Redis situation - steward changes the license, someone large enough to maintain a fork creates one, and everyone moves to the fork. In Redis's case, Amazon forked it into Valkey.
Spring is so widely used that there are multiple "large enough" companies who could do this
What's the actual risk though? Just saying it's the riskiest at 77/100 doesn't mean anything.
Among others:
- license change -> restricting features behind a paid tier (https://spring.io/blog/2025/04/21/spring-cloud-data-flow-com...)
- reducing headcount of people -> slow security patching + not following industry standards
- all eggs in one basket :)
- cut from major clouds (Azure Spring apps)
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:
[pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8
That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs.
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
I mean I understand that's the goal, but in this specific CVE it looks like the issue was introduced in Bitnami's own scripts sitting on top of everything, so a ideally-zero-CVE underlying OS isn't going to solve that problem at all.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
"Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license."
Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?
This is going to cause some disruptions. What are the alternatives out there to bitnami charts?
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.
What about the bitnami:minideb base image? Or the stacksmith files necessary to build certain images? Without access to these resources, it will not be possible to rebuild the images, will it?
Projects like Sealed Secrets and minideb remain unaffected by these changes. Container images for both projects will continue to be released on Docker Hub (docker.io/bitnami) as usual, without any modifications.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
Seems to be Apache 2 https://github.com/bitnami/minideb/blob/1694284885fecfb852b0... and it has GHA (although I didn't verify that it could plausibly run outside of their GH org) https://github.com/bitnami/minideb/blob/1694284885fecfb852b0...
https://artifacthub.io/
I don't know why but Artifact Hub never shows up in Google search when you search for "web site with helm charts". Hopefully this gives it a boost.
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.
My first thought was Linuxcontainers but I think they just maintain docker images, not helm charts
They're all open source - fork the repo and start collectively maintain them.
That doesn't really answer the question, does it?
You asked for an alternative and that seems like an alternative to me.
It's not and I wasn't the one who asked
K
RabbitMQ next?
Great more enshitification! Broadcom is destroying everything they touch
That's nonsense. RPi would not exist if not for Broadcom.
The current Broadcom (Avago) is literally not the Broadcom that RPi came from. Not that old-Broadcom was great, but...
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.
Yeah Broadcom had a load of unsellable SOCs they needed to off load
But who will think of the shareholders?! \s
I’m surprised anybody works at bcom these days.
this blows.. i have to use bitnami charts for a bunch of stuff, have for a while..
That's fine , their repmgr postgres repository was a joke.
"Discontinuing this library of 120 things for everyone is fine, *I* didn't like *one of them* I won't say why"