I don't want to discount the work they are doing, and that it has no value, but a little bit shocking that they expect to go all commercial with this, in the Oracle way, while just "packaging" and so relying on open source software that they will not contribute to.
Also, I'm a little bit wondering at how much all of this is really copyrightable in the end.
Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".
And it might be each the single and obvious way to package the thing anyway.
And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...
"Makefile" they have written and copyrighting is very non trivial and there are many man-months of effort. Configuring all sorts of software just with env vars and make it usable is not an easy feat.
What probably carries more value is the helm charts that they provide which are also on their way out.
The images themselves have official replacements (for example, looking at https://hub.docker.com/u/bitnami why wouldn’t I use Node or Postgres images from the official sources instead).
I have no idea how many people actually used their helm charts though.
> However, in order to sustain and support the dedicated team of engineers who maintain and build new charts and images, a subscription will be required if an organization needs the images and charts built and hosted in an OCI registry for them.
This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
> Essentially, Bitnami has been the Jenkins of the internet for many years, but this has become unsustainable.
It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software that maybe corresponds to a level 2 on the OperatorFramework capability scale[1] - usually more of a 1.
> It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software
I'm not going to defend a corporation but this sentence feels very entitled. They were providing it for free, you could use it. They are not going to provide it for free anymore, you migrate to something else or self-maintain it and say "thank you for the base work you did I can use now"
>This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
You seem to be confused about who Broadcom is and how they operate. "Long term health" isn't a thing for them. They buy products that are embedded deeply in the fortune 500, cut 90% of the staff, and increase licensing and support 2-100x. They do not care if you are upset. They do not care if you're going to "find something else". They don't care if you build an entire campaign to decry what they're doing.
They know the F500 cannot easily remove them, and that they will have at minimum 5 years to print cash on their service contracts. Sure, some of those F500s will sue them and try to stop the extortion via legal means, but they know that they'll either win, or at worst still be allowed to jack up prices even if a court rules it's not their original egregious asking price.
Building Infrastructure company is challenging in 2025. Previously, you would prioritize traction among developers over focusing on revenue.
But that does not work in 2025. You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.
If their contribution is minimal then the impact of this change should also be? But it appears it disruptive so they have been showing up for a long time and that’s one of the most difficult things.
In the end, they have to do it because of the CSR, and they can do it because of the CSR.
The European Union Cyber Residence Act has the potential to drastically change the open source ecosystem.
The new regulation pushes the due diligence for security according to the Act towards any entity making a commercial offer based on open source software.
Caveat emptor!
For any enterprise, that means that they either do extensive documentation and security on open source components they use or they use foundation or enterprise-backed products.
Note that pure uncommercial open source projects are exempt from the Act.
I see this as a chance; we can still create open and free software, and those of us who desire financial compensation from those who make money with their work can offer as a necessary compliance framework as a service via a different entity.
I don't agree, they have to do all the CSR due diligence for the commercial offerings based on those open source projects, so there is no difference. The effort has to be done regardless if there's part of it that is open source and free, or not.
They don't have to. They can do the paid secure images for the commercial offerings and keep the other ones free. Or they could free the secure images for everyone if they feel like that.
If you’re looking for an alternative here, we (the team that built Twistlock) launched Minimus a few months ago to provide near zero CVE images built continuously from source. We have long experience in this space (we even wrote NIST SP 800-190) and I’d love to talk if we could help anyone. We also have drop in replacement images and charts for Bitnami, as we describe here: https://www.minimus.io/post/the-bitnami-pricing-changes-what...
If anyone has tech questions about how it all works, tools we use, customer scenarios, etc I’d be happy to discuss.
Also, this form is nonsensical https://www.minimus.io/get-started#signup-form because it distinguishes between "Individual" and "Organization" but then Company is a mandatory field. Maybe just go ahead and label it "Lead Gen / Ask For A Demo"
Let me rewrite the comparison used in the "Example: Using Bitnami vs. Minimus" section of the blog post:
Using Bitnami Secure Images:
You pull a versioned PostgreSQL image built on a minimal-attack-surface OS (Photon). When a CVE is disclosed or a new upstream version is released, Bitnami’s automation takes care of everything: a new container image (and Helm chart, if applicable) is built, tested, and published to your registry within hours.
All you need to do is update to the latest version; no manual CVE monitoring, triage, or patching required.
The main question as always is price. I was also interested in things like Chainguard and Docker secure images until I had a sales call with them and found out the price.
I can’t seem to find the price anywhere on your site… I assume the reason for that is that it’s also nearly impossible for a non-fortune 500 to afford?
Please offer an implementation of the docker-credential helper, just like chainguard does with docker-credential-cgr[1], and don't put throwaway text that says "docker supports credential stores, so good luck to you" on your website https://docs.minimus.io/foundations/authentication#using-a-c...
I advocated an enterprise to migrate away almost two years ago now. In enterprise time that means the project to do so is just about complete, so I am feeling pretty vindicated just now.
I was never a fan of images from Bitnami. They always used complicated entrypoint and setup scripts, and introduced weird quirks to the software. More than once have I experienced issues or ran into configuration limitations with Bitnami images that didn't exist in official ones.
So good riddance, as far as I'm concerned. I recommend anyone to avoid using them, and switch to official images or to build them yourself if they're not provided. That's the more secure approach, anyway.
The way I see it, a software project has only (1) code you maintain or pay someone to maintain for you, and/or (2) throwaway code that you will eventually need to replace with an incompatible version.
Nothing wrong with a project that is just gluing throwaway code because it's a gamble that usually pays off. But if that code is from third-party dependencies, just don't believe for a second that those dependencies (or any compatible forks) will outlive your project, or that their developers have any incentive at all to help you maintain your project alive.
It is sad to see how Broadcom cannot do padding right for mobile…
But on topic: why not create docker.io/bsi and let /bitnami as is without new updates? Then nothing breaks; it just won’t be possible to do upgrades. You’ll then figure out why and possibly seamlessly switch to your own build or BSI.
> But on topic: why not create docker.io/bsi and let /bitnami as is without new updates?
If people are relying on you for automatic security updates, and you've decided to no longer provide these updates [for free], users should opt in to accept the risk.
This would normally require user action (after a period of warnings/information), and having the fix look 'obviously' unsafe (`/bitnami ` ->`/bitnamilegacy`) feels reasonable.
I never understood the point of Bitnami. Every time I tried one of their image / package, it's a complicated mess full of custom and strange stuff, really hard to work with.
Instead of a simple package of the software based on some familiar base, you get some weird enterprise garbage that follows strange conventions and a nightmare when you need to customize anything.
At my last gig I avoided Bitnami container images and Helm charts wherever possible. We (me plus an AWS consultant) used Karpenter Autoscaler, Envoy Gateway API, Gatekeeper OPA, Loki/Prometheus/Grafana Stack, EDB Postgres Operator, ... and deployed all through a single comprehensive terraform script to an EKS cluster. I tried to keep reliance on one single company as low ad possible. I even had a Plan B to replace S3 with MinIO in case the company decided to move to another cloud provider or an On Prem Kubernetes cluster.
My recommendation to everyone is to avoid Cloud Vendor Lock-In from the start, and even if it's more initial work, to try to have as much as possible running on Kubernetes.
Good to see they decided to delay a bit and do some brownouts first. I took a quick look at the Docker hub stats (https://raesene.github.io/blog/2025/08/21/bitnami-deprecatio...) and it looks like some of those images are still getting hundreds of thousands or even millions of pulls a week.
Meanwhile if anyone wants images with dramatically higher supply chain security than anything Bitnami ever offered, and free to the public forever, check out stagex.
As the only multisigned, full source bootstrapped, reproducible, and container native distro that exists, it does not matter what registry you pull from because the digest is the same everywhere.
We publish all images to both dockerhub and quay and signature checks pass either way so mirror anywhere you want.
Anyone claiming they need to host in a particular registry for security is gaslighting you.
Commonly used in microcontrollers to describe supply voltage dropping below threshold. It could cause RAM corruption, erratic behaviors of robots, overshoot in voltage regulators, battery fluid leaks etc., and so optional detection features are often made available to reset or stop the processor and notify the application on next boot.
It's also used in utility power supplies to describe line voltage going below spec. It's considered a dangerous condition in that context too, as lots of non-smart equipment tend to run at higher amperage at lower voltage and/or fail to start/run and catch fire.
We did this at stripe when deprecating TLS 1.0, and called it a brown out (I don't know the origin of the term in software).
You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)
I wonder what the effect of their helm charts will be. As far as I know the charts play well together with their own images but not necessarily with other images (like the official images). Also in some cases particular versions of helm charts are needed for particular versions of the application/images.
So then there are no tagged versions of the images. How will this affect the future of the charts? The old (existing) charts can easily point to the old images in the legacy repository. But how about future development? Will this be stopped, so the charts will remain in the existing state? Or will it be continued but point to the new "latest" images - which means the chart/image combination could break at any time?
Bitnami has a number of docker images that are returned by search results (https://hub.docker.com/r/bitnami/redis-sentinel was one that I came across a while ago), and even before this I was concerned about how their images keep getting returned by search results.
I thought I was paranoid, not wanting to have containers that rely on an organization that I didn't know much about (I didn't know that Bitnami was part of Broadcom/VMW), but this just proves my worries were well founded.
I use a few bitnami charts, and I'm now going to have to migrate them.
For everyone here surprised that anyone would use them, here's some context from my perspective: as a small startup, having a pre-configured Kafka chart was a lifesaver, where I only needed to tweak the parameters I was interested in, which took me a lot less time than setting up a whole Kafka environment from scratch. It was relatively quick to setup, and felt like the right move to put something like Kafka in production (and not have to pay for Confluent when everything else is self hosted)
[+] [-] greatgib|6 months ago|reply
Also, I'm a little bit wondering at how much all of this is really copyrightable in the end. Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".
And it might be each the single and obvious way to package the thing anyway.
And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...
[+] [-] nopurpose|6 months ago|reply
Have a look at https://github.com/bitnami/containers/tree/main/bitnami/post... as example.
It might be worth a commercial license for some of their current user-base, no doubt.
[+] [-] supriyo-biswas|6 months ago|reply
The images themselves have official replacements (for example, looking at https://hub.docker.com/u/bitnami why wouldn’t I use Node or Postgres images from the official sources instead).
I have no idea how many people actually used their helm charts though.
[+] [-] asmor|6 months ago|reply
This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
> Essentially, Bitnami has been the Jenkins of the internet for many years, but this has become unsustainable.
It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software that maybe corresponds to a level 2 on the OperatorFramework capability scale[1] - usually more of a 1.
[1]: https://operatorframework.io/operator-capabilities/
[+] [-] darkwater|6 months ago|reply
I'm not going to defend a corporation but this sentence feels very entitled. They were providing it for free, you could use it. They are not going to provide it for free anymore, you migrate to something else or self-maintain it and say "thank you for the base work you did I can use now"
[+] [-] kpcyrd|6 months ago|reply
That's a wild take for "somebody provided something for free but decided they don't want to anymore".
Sucks for you, looks like you have to do your job yourself now.
[+] [-] tw04|6 months ago|reply
You seem to be confused about who Broadcom is and how they operate. "Long term health" isn't a thing for them. They buy products that are embedded deeply in the fortune 500, cut 90% of the staff, and increase licensing and support 2-100x. They do not care if you are upset. They do not care if you're going to "find something else". They don't care if you build an entire campaign to decry what they're doing.
They know the F500 cannot easily remove them, and that they will have at minimum 5 years to print cash on their service contracts. Sure, some of those F500s will sue them and try to stop the extortion via legal means, but they know that they'll either win, or at worst still be allowed to jack up prices even if a court rules it's not their original egregious asking price.
[+] [-] debarshri|6 months ago|reply
But that does not work in 2025. You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.
[+] [-] pst|6 months ago|reply
[+] [-] venkyvb|6 months ago|reply
[+] [-] unknown|6 months ago|reply
[deleted]
[+] [-] unknown|6 months ago|reply
[deleted]
[+] [-] pacifika|6 months ago|reply
[+] [-] j45|6 months ago|reply
[+] [-] unknown|6 months ago|reply
[deleted]
[+] [-] niemandhier|6 months ago|reply
The European Union Cyber Residence Act has the potential to drastically change the open source ecosystem.
The new regulation pushes the due diligence for security according to the Act towards any entity making a commercial offer based on open source software.
Caveat emptor!
For any enterprise, that means that they either do extensive documentation and security on open source components they use or they use foundation or enterprise-backed products.
Note that pure uncommercial open source projects are exempt from the Act.
I see this as a chance; we can still create open and free software, and those of us who desire financial compensation from those who make money with their work can offer as a necessary compliance framework as a service via a different entity.
[+] [-] sofixa|6 months ago|reply
[+] [-] tecleandor|6 months ago|reply
[+] [-] morellonet|6 months ago|reply
If anyone has tech questions about how it all works, tools we use, customer scenarios, etc I’d be happy to discuss.
[+] [-] mdaniel|6 months ago|reply
[+] [-] carrodher|6 months ago|reply
Using Bitnami Secure Images: You pull a versioned PostgreSQL image built on a minimal-attack-surface OS (Photon). When a CVE is disclosed or a new upstream version is released, Bitnami’s automation takes care of everything: a new container image (and Helm chart, if applicable) is built, tested, and published to your registry within hours. All you need to do is update to the latest version; no manual CVE monitoring, triage, or patching required.
[+] [-] CubsFan1060|6 months ago|reply
I can’t seem to find the price anywhere on your site… I assume the reason for that is that it’s also nearly impossible for a non-fortune 500 to afford?
[+] [-] Beltran|6 months ago|reply
[+] [-] mdaniel|6 months ago|reply
1: https://edu.chainguard.dev/chainguard/chainguard-images/chai...
[+] [-] gexla|6 months ago|reply
[+] [-] MathiasPius|6 months ago|reply
It's a shame that competition for this position has been ramping up lately.
[+] [-] ehnto|6 months ago|reply
[+] [-] imiric|6 months ago|reply
So good riddance, as far as I'm concerned. I recommend anyone to avoid using them, and switch to official images or to build them yourself if they're not provided. That's the more secure approach, anyway.
[+] [-] quectophoton|6 months ago|reply
The way I see it, a software project has only (1) code you maintain or pay someone to maintain for you, and/or (2) throwaway code that you will eventually need to replace with an incompatible version.
Nothing wrong with a project that is just gluing throwaway code because it's a gamble that usually pays off. But if that code is from third-party dependencies, just don't believe for a second that those dependencies (or any compatible forks) will outlive your project, or that their developers have any incentive at all to help you maintain your project alive.
[+] [-] rahkiin|6 months ago|reply
But on topic: why not create docker.io/bsi and let /bitnami as is without new updates? Then nothing breaks; it just won’t be possible to do upgrades. You’ll then figure out why and possibly seamlessly switch to your own build or BSI.
[+] [-] david_allison|6 months ago|reply
If people are relying on you for automatic security updates, and you've decided to no longer provide these updates [for free], users should opt in to accept the risk.
This would normally require user action (after a period of warnings/information), and having the fix look 'obviously' unsafe (`/bitnami ` ->`/bitnamilegacy`) feels reasonable.
[+] [-] orthoxerox|6 months ago|reply
[+] [-] cube00|6 months ago|reply
It's on brand when you consider how badly the styling in Rally needs an update.
[+] [-] wilonth|6 months ago|reply
Instead of a simple package of the software based on some familiar base, you get some weird enterprise garbage that follows strange conventions and a nightmare when you need to customize anything.
[+] [-] de6u99er|6 months ago|reply
My recommendation to everyone is to avoid Cloud Vendor Lock-In from the start, and even if it's more initial work, to try to have as much as possible running on Kubernetes.
[+] [-] raesene9|6 months ago|reply
[+] [-] zdkaster|6 months ago|reply
[+] [-] unknown|6 months ago|reply
[deleted]
[+] [-] unknown|6 months ago|reply
[deleted]
[+] [-] lrvick|6 months ago|reply
https://stagex.tools
As the only multisigned, full source bootstrapped, reproducible, and container native distro that exists, it does not matter what registry you pull from because the digest is the same everywhere.
We publish all images to both dockerhub and quay and signature checks pass either way so mirror anywhere you want.
Anyone claiming they need to host in a particular registry for security is gaslighting you.
[+] [-] prmoustache|6 months ago|reply
[+] [-] numpad0|6 months ago|reply
It's also used in utility power supplies to describe line voltage going below spec. It's considered a dangerous condition in that context too, as lots of non-smart equipment tend to run at higher amperage at lower voltage and/or fail to start/run and catch fire.
1: https://developerhelp.microchip.com/xwiki/bin/view/products/...
[+] [-] habitue|6 months ago|reply
You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)
[+] [-] Beltran|6 months ago|reply
[+] [-] 01HNNWZ0MV43FF|6 months ago|reply
You intentionally break something just a little to force dependents to notice, before turning it off completely
[+] [-] micw|6 months ago|reply
So then there are no tagged versions of the images. How will this affect the future of the charts? The old (existing) charts can easily point to the old images in the legacy repository. But how about future development? Will this be stopped, so the charts will remain in the existing state? Or will it be continued but point to the new "latest" images - which means the chart/image combination could break at any time?
[+] [-] nloomans|6 months ago|reply
[+] [-] sc68cal|6 months ago|reply
I thought I was paranoid, not wanting to have containers that rely on an organization that I didn't know much about (I didn't know that Bitnami was part of Broadcom/VMW), but this just proves my worries were well founded.
[+] [-] ajd555|6 months ago|reply
[+] [-] skibz|6 months ago|reply