> 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"
Aye, It's a bit like saying you can't sell your code, because you wrote it in someone elses software.
Writing a decent Dockerfile isn't hard, and keeping it maintained and working with new versions is still work and it's past the wheelhouse of very many people. It's entirely reasonable to want paid for that effort.
That said, it's not work I personally value enough to put my hand in my pocket, and that's a fair take too.
I think it's perfectly fair for them to say "we're not doing this any more". The sketchy part is deleting the public registry at docker.io/bitnami rather than just no longer updating it. Why can't docker.io/bitnami become the 'legacy' registry, receive no future updates, so at least folks who don't hear this news won't have pulls suddenly fail?
edit: like if I have a package on NPM and I want to stop offering it, I think it's shitty to just delete it. That breaks builds.
Vendor lock-in is a thing. Switching costs are a thing. They know this. That's the whole business model. They're expecting that the cost of switching to outweigh the cost of the subscription.
I get that this business model is fashionable amongst wannabe rent-seekers, but it's still antisocial and should be shunned.
This is not rent-seeking: Rent-seeking is leveraging your position to garner economic rents, like putting a toll gate across a highway in which the only value received for the toll is the opening of the gate.
Rent-seeking would be Broadcom saying that you must run a Bitnami image in CloudFoundry or pay a penalty for not doing so. They are in fact doing some work here. We may disagree on whether or not they're being compensated fairly for that work, but that disagreement doesn't turn this into "rent-seeking"
The penalty is the work of migrating away and redoing any integration work on a month's notice. That might seem trivial to a small deployment, but I know some people that use these images everywhere, including in places that aren't immediately obvious.
Not to mention a lot of people that are going do be doing this work are the same people also spending the year swapping out hypervisors which is also no small task.
Evaluating the risks of vendor lock-in is a buyer's task, unless it is a protected market or there is a monopoly abuse involved.
In this case, nobody forced (generic) you to use Bitnami's Docker images, you probably just thought "how convenient, always updated and easy to pull, one less thing to worry about". Which is fine, but it's always a bet on what will happen in the future.
Yes, yes. And a person who's pick-pocketed may well do better to protect their pockets. This does not absolve the thief.
Reasonable people can disagree about the degree to which vendor lock-in is antisocial or the degree to which there even is vendor lock-in here. But telling victims of such behavior to just suck it up and price it in only serves to distract from and abet actors abusing positions of power to rent seek and create low trust environments. It's not a systemic solution and it's not a serious engagement with the criticism levied.
> Yes, yes. And a person who's pick-pocketed may well do better to protect their pockets. This does not absolve the thief.
Freedom of roaming without having to worry about pickpockets it's one thing. Deciding that you go with the opensource offering of a company because it's convenient for you is another.
I know it's just one example but the entitlement here is _the key_. You are entitled to go to whatever zone of a city and it's not right to blame the victim in that case. You are not entitled to have part of the business decisions of a company you were a "client" without paying a dime or signing any binding contract.
You would be entitled to that if they were breaking some opensource license, for example.
Just because you want that to be "the key" doesn't make it so. You make that your singular focus and you let antisocial behaviour off the hook. That is your prerogative.
For me, the key is the bait and switch. It's like a drug dealer offering first time customers a discount. It's a good business strategy to get people hooked. Very enterprising. Nonetheless, I would prefer a society without such behaviour.
When a project is abandoned, when updates are slow, when features people want are not being released, when tracking upstream dependency updates are delayed, sure, you are not entitled to anything and I’ll be the first one to say get off your butt and contribute. In the other hand when you engage with the community for years under an OSS/free context then once the community has invested in your project, learning it, creating learning resources for it, integrating it into their own projects, and you never communicated your intention to “wait until it gets big then then pull the rug” it feels like a disingenuous bait and switch. The reason it feels that way is because it is a disingenuous bait and switch. This is even more so the case when you built your project on top of other projects.
I have no problem using a paid product or service or paying for support on a OSS product, but will never pay one of these bait and switch scams a dime, no matter how much engineering effort it takes.
I understand the sentiment and where it comes from, and I'm not saying it's a good decision from Broadcom (I think it is a bad one indeed!). But still, this risk is part of the game. Even if it was full opensource and with a broad community, it was still a single vendor, not even a non-profit umbrella like the Apache or Linux Foundation. So, the risk of trusting a single vendor was there.
The good thing of it being opensource is that someone else (company, community, foundation or whatever) can step in, fork it, and maintain it from now on, unlike what happens with proprietary software or SaaS.
What do you mean, that's the business model more than half the VC-funded startups now. Provide something for free or near free, wait until your customer is dependent on you and/or consolidate into at least an oligopoly and then put the thumbscrews on.
I find that to be a pretty dishonest business model. I don't have any Bitnami images to replace, but I know a lot of people who do without ever having made that choice - and their bosses aren't going to pay Broadcom for the most part either. So you end up with overworked developers that now hate Broadcom and/or a whole lot of deployments that just break or never get updated. The number of people going "I can just switch over to the archive image, whatever" on the K8s subreddit alone is concerning.
The Bitnami images and helm charts are just convenient repackaging of things that are already freely (gratis) available. There's nothing stopping you from still deploying Kafka or Redis, etc. into your k8s cluster without using the Bitnami helm chart or building your own charts.
I think that's the point of above of "now you have to do your job"
There's an evaluation that takes place when choosing to use something as an engineer, and the writing should have been on the wall the moment that Broadcom bought Bitrock to start planning to reduce dependency on those things.
> What do you mean, that's the business model more than half the VC-funded startups now. Provide something for free or near free, wait until your customer is dependent on you and/or consolidate into at least an oligopoly and then put the thumbscrews on.
You skipped the part where you bankrupt your competition in the space who can't afford to hemorrhage cash they don't have like a VC-backed startup can, hoover up all the customers, then charge more than the old guard industry did in the first damn place for a worse version of the same service, while also paradoxically paying any workers needed to provide said service even less than they were making before.
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.
The problem I think is that all the easy infrastructure problems have been solved and the market is crowded with those solutions. Solving the hard problems is probably where you could have a viable business but I don't really see that many companies trying to solve those:
* Making mono-repos work for large companies.
* Mixed language builds are still a ci/cd unsolved problems for most companies.
> Previously, you would prioritize traction among developers over focusing on revenue.
A.k.a. using open source as a marketing tactic to lure in customers, only to do a rug pull once the business gains enough momentum.
> But that does not work in 2025.
Good. It is an insidious practice. There are very few projects that actually do this properly without turning their backs on the users who made their products popular in the first place.
> 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.
The strategy of delivering valuable products that benefit users without exploiting them has always existed. The thing is that many companies choose the greedy and user hostile path, instead of running a sustainable business that delivers value to humanity and not just to shareholders, which is much more difficult. So I have no sympathy towards these companies.
No, the struggle is fully manufactured by this rug pull. If I had known this was going to happen when I was setting up my infra I could've used any number of other alternatives, including just building them myself, at little to no extra effort. Now I have to waste time migrating off of these.
The problem isn't paying for it, it's the extra workload of retrofitting authentication to all your things. I'd find this a lot more enticing if they just made you set a "i have a license or i am evaluating or i am not commercial" flag in Helm or fail the build. Plus the cost is extremely disproportionate, but some will pay it given the one month deadline.
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.
That's like saying, "Honda isn't a car company, they're an assembly company because they don't mine the minerals to make the parts and rely instead on supply chains"
Well, Bitnami didn't produce own hardware stack either ;) Joke aside, it's not naive - CentOS, Alma, Rocky, Ubuntu... FOSS community has some experience with these things
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.
You seriously underestimate this in general case. Build system may be made in weeks, but is polished in months or even years, to account for all the different usage and environment scenarios. Otherwise, it's typically very fragile.
Which is why I think you should not try to build generic images like this. I looked at the source and it seems like s lot of work had been put into creating a fragile mess.
After having been burned several times by images I prefer writing my docker images from scratch (based on the Debian or Alpine images) for production systems. I only use ready-made images for quickly getting something running locally to evaluate it.
Wasn't the point of the post you replied to that it isn't just a simple makefile ? That repo contains quite a lot carefully assembled scripts for each image that handles a lot of corner cases.
It is a lot of work but it is work that for the most part should not have been done. I took a quick look at the code (since I know PG very well) and I would not recommend anyone to use that mess off Bash code which configures PostgreSQL in an annoying and incorrect way and exposed some arbitrarily select settings in the environment (some very rarely used) while you have to do most in the config file. Better to just write your own Docker image for scratch, or use the official PG image of your needs are simple.
This is what happens if you merge every feature request you get and do not have a clear plan or architecture. After reading the code I am happy they are deleting the images, at least if this one is typical.
As a PostgreSQL expert I can write a much better image which suits my needs in one day, which I have also done several times. It would be harder for a non-expery but I do not think a non-expert should use this image due to some footguns I spotted. This kind of generic image is a bad idea and very hard to build.
Hindsight is 2020, there’s now helm/kubernetes operator under the cloud native umbrella. I’m sure they took in all the mistakes from here. This helm chart is getting long in the tooth, but is still monumental. Imo running psql on kube is a mistake to begin with but here we are.
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.
They do keep some of them more up to date, for example the bitnami python image had system packages patched faster than the official one. But if you are willing to pay then chainguard is a better solution.
Alpine helps but it's not perfect. Plenty of outdated packages with known CVEs there for long time.
Often they are not exploitable but it's easier to pay chainguard to have a constant zero on our vuln scanner than to deal with distroless builds ourselves.
Right, I deal with NIST 800-53 based things where we have heavy albeit manual auditing. We pull from Iron Bank mostly but also employ Nexus Firewall. People can’t pull direct Docker Hub.
For what it's worth, their pricing has decreased substantially over the last year. Their most recent quote to us was about 25% of the one we received a year or so ago.
For some more transparency, we pay ~$9k/year per image (all versions/variants) for some basic images (think python, golang etc). The ones with cuda drivers are more expensive but I don't have the exact prices on hand.
Some other open source projects have also shipped Bitnami software in their own helm charts, i.e. APISIX's etcd instance is the Bitnami chart pulled in as a dependency.
Not that it ever worked well, we had to scale it to 1 because the quorum would constantly break into unrecoverable states.
My team is worried about that too. We've been a java and spring shop for years. We're looking at micronaut, it's similar enough.
When I had someone from another team take a look at broadcom and what they could do to spring, they said the licenses are permissive, it will be fine. Likely not that simple.
- Shorter support windows, with longer support available for purchase (VMWare actually introduced this, but Broadcom can weaponize it)
- Then Enterprise Spring, which has additional features
- Then some other license shenaningans.
Hazelcast recently made the move where CVE security updates are only released into the OSS ecosystem quarterly - whereas the enterprise model gets them as soon as they're ready. In OSS, you have to rebuild and patch yourself.
That's a special kind of evil, which has Broadcom DNA all over it.
They're still technically Avago Technologies, just wearing the name of Broadcom after the acquisition in 2015-2016. Not sure if there's much of Broadcom left, beyond the name and what IP they had at the time which was not sold off, like they did with the IoT related IPs.
Taking a bunch of projects and making containers and flexible helm charts for them is kind of an interesting model. It’s what Redhat and Canonical do with raw Linux packages; they charge for premium support and even patches or extended support.
I was going through one of my clusters, I have two bitnami uses and they are both ‘building blocks’ I use Trino, which uses a metastore which uses postgresql and then some other package uses redis. It seems like both postgresql and redis could/would have containers and charts to install their stuff, where it breaks is the postgresql guys probably want to support “current” and not 4 major releases back, which is kind of normal to see in the wild.
It is kind of an interesting model, I’d love it if rancher or openshift or someone started to seriously compete. Shipping a Kubernetes in a box is nice but if they started packaging up the building blocks, that’s huge too.
Broadcom has always been about pure evil (cough capitalism cough), you just haven't been affected by it before. Ask anyone who's worked with their hardware...
So
Others have already provided good answers. I wouldn't classify it as evil if all they did was to stop maintaining the images & charts, I recognise how much time, effort and money that takes. Companies and open source developers alike are free to say "We can no longer work on this".
The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
I know Broadcom inherited Bitnami as part of an acquisition and legally have no obligation to do anything, but ethically (which is why they are evil, not necessarily criminal) they absolutely have a duty to minimise the damage, which is 100% within their power & budget as others have pointed out.
And this is before you even consider all the work unpaid contributors have put into Bitnami over the years (myself included).
It's also entirely fine if they delete these images to me. But not with a week of time frame, as originally intended.
And sure, we can go ahead and discuss how this being free incurs no SLAs or guarantees. That's correct, but does not mean that such a short time frame is both rude and not a high quality of offering a service. If I look at how long it would take us to cancel a customer contract and off-board those...
And apparently it costs $9 to host this for another month? Sheesh.
> The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
Something, something, sticking your hand in a lawnmower and expecting it not to be cut off.
that's an assumption, but Broadcom is most likely using open source software in all of their apps. So they do have a moral to also give something back. So just saying it's fair that they don't want to provide something for free anymore isn't really all that fair.
Oh don't get me wrong, my claim is that they are not even clearing the absolute lowest bar when it comes to their stewardship of the Bitnami repositories: Do no harm.
The images are currently in Docker Hub. If $9/month (or $15, not 100% sure if $9 includes organizations) to keep those images available is too much for Bitnami I'm sure there are many organizations who wouldn't mind paying that bill for them (possibly even Docker Hub itself).
Broadcom is deciding to host it on their own registry and bear the associated cost of doing so. Not sure what this has to do with sponsoring network egress
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.
100% agreed. I don’t understand the point of throwing all conventions out the window and building their own brittle scripts on top of it. All their images require docs to configure because none of the upstream documentation applies.
I've used them as a quick way to get rootless configured base images. Not sure if official repos provide those now, but it used to be a big hassle to get things like postgres images running without root in their containers. Although I often had to read through their dockerfiles to figure out the uid setup, where configs live, etc because they were not consistent between the various bitnami images.
Back in the day, Bitnami was a way to run Wordpress on Windows. They packaged it nicely so that you could install it on Windows Server. Nowdays that could get you fired, but back then Linux was not so widespread.
What are some resources for these conventions? As far as I can tell everyone else rolls their own bespoke images based off of of a projects image in order to customize the configuration.
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"
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?
Nope - we're early stage so we're really flexible not just on pricing but licensing terms too. We have many customers that are smaller startups, not just typical F500 types.
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...
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.
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.
Hmmmm, I'm not sure that's how it would be read. If there's any 'associated commercial activity', it falls under the CSR, even if the images themselves are free and open source.
(That said, the overhead of the CSR is really not much, from what I can tell. It's pretty lightweight as EU standards go)
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.
Just to be crystal clear about the open source part: the code for all container images will continue to be maintained, kept up to date, and publicly accessible on GitHub (https://github.com/bitnami/containers) under the Apache 2 license.
What Bitnami is discontinuing is the publishing of prebuilt images to public registries. However, the build code remains available, so users can still build the images themselves and push them to their own registries by running a couple of commands.
> BSI is effectively democratizing security and compliance for open source so that it doesn’t require million-dollar contracts from vendors with sky-high valuations.
I suppose 50k isn't a million dollar contract, but it's certainly also not "democratizing" anything
Depending on your needs, this could be a bargain as advertised. It's only expensive relative to what you can build on your own, or what competitors offer.
It's a bit tricky to work through all the jargon, but it's my understanding that they are simply pulling the mass of things that they provide for free. You can still get the Docker files for their offerings (not sure they offer all tags though?") and you can even use the images from Docker Hub.
But. What they are offering is considered "development" regardless of what you are using it for? In other words, NOT a production environment, because they aren't giving you a production environment (or at least what they define as a production environment.) What they give you for free is the "latest" and on a Debian system.
What they offer as "secure" is running on Photon OS and goes through a security pipeline, etc. They aren't holding anything back aside from the services they provide.
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.
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.
Any brand value that bitnami has will be entirely destroyed by this incomprehensible change. People will associate the ‘bitnami’ namespace with “can’t possible utilize for long term production use”
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 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?
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)
Almost the same situation here. The only thing I used was Kafka, and I only used that to allow horizontal scaling of Argo Events sensors. Moved over to jetstream, saved a bunch of compute and memory, and realized I didn't need to scale Argo's sensors horizontally. Really, Bitnami's decision made my life easier in the end.
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.
Thanks for mentioning these! Do you know what are the official channels they're doing the announcements in? In the post they just mention the word "usual" with no clarification.
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)
There was actually a really terrible brown-out by Poetry (a Python dependency management and packaging tool) where they introduced sporadic failures to people's CI/CD systems: https://github.com/python-poetry/poetry/pull/6297
It refers to a situation where a system is deliberately designed to fail (usually for short periods of time), to still provide some level of service while alerting others that the system is soon to be turned off.
That is not where the term comes from. Lights out -> Blackout (WWII, to stop overflying aircraft from having easy targets and to disrupt navigation). Reduced voltage on the grid -> lights go from white to orange and eventually to brown, not quite a blackout -> brown out.
The OED reports that the disrupted-electrical supply sense of blackout was first used in 1934; the air-defence one (no light) in 1935. However, the OG use seems to be in the theatre, where the lights are shut off during set changes (1913, probably earlier).
Brownout does seem to be a WWII-era term, but more related to conservation/shortages than air defence.
Don't know the origin, but with no technical background past using Linux, I only ever heard of brownouts in contexts of failing (often 3rd world) electrical infrastructure. Mostly Africa and South America (don't mean to offend anybody living there, I know they're vast continents with many rich/infrastructure-stable countries too).
Origin is the electrical grid overload which caused incandescent lights to literally "brown out", as has been mentioned here.
Later is was coopted to mean any problems with power supply not including outright drop to zero-zero/disconnections. cf microcontroller brown-out handling, also mentioned above.
Then later it seems it was generalized to mean sort-of-non-terminal problem with supply of most anything.
“If you’re looking to deploy multiple images, Chainguard’s per-image charges could quickly exceed Bitnami’s flat subscription cost. For example, licensing 3 images at $30K each would already reach $90K/year.” via Reddit.
There is a new Catalog option. Their pricing is “custom” and not published online so all we have is Reddit anecdotes like here
Updating the Bitnami images is probably a bit of a challenge. From looking at them last year, I believe that they are build around a Bitnami style/framework. They are confusing at best.
If you're Bitnami it probably made sense to do it the image the way they did, but for everyone else, it's just a massive complication.
Personally I don't understand why anyone would have opted to use the Bitnami images for most things. They are really large and complex images and in most cases you'd probably be better of building your own images instead.
My guess is that there's a very small overlap between people who want to maintain Docker images, and the people who chose to run Bitnamis images.
The Docker images are complex for the sake of the Helm charts, which sometimes need to pass down tons of parameters
These aren't just for your laptop, they're supposed to be able to run in prod
I'm still stuck with 3 bitnami charts that I keep updated by building from source, which includes also building the images, all on our private registry.
That makes some sense. I've only used Bitnami images with Docker compose or as standalone containers. In those case you're frequently better of just mounting in a configuration file, but that won't really work in Kubernetes.
I would argue that if you run Kubernetes, then you frequently already have the resource to maintain your own images.
I had not used bitnami images for.. probably 5 years at this point and they always seemed servicable in a pinch, usually used for testing and I when I brought this up recently I was also told (by k8s users) that the helm stuff is probably what actually has most people up in arms because it is very common. We're the minority who remember bitnami as a non-critical choice among many.
> Personally I don't understand why anyone would have opted to use the Bitnami images for most things.
At my previous company, we used it because of the low CVE counts. We needed to report the CVE count for every Docker image we used every month, so most of the images were from Bitnami.
There are many enterprise companies freeloading on Bitnami images, and I’m surprised it took Broadcom this long to make this change.
Wait... this whole time reading this thread, I'm racking my brain for what bitnami provided (I used to use them before docker came around. I never would have got Redmine up and going without them -- the install seemed so foreign.) that building a docker image couldn't, because surely everyone knows how to build one from scratch, right?... right?
Is all the panic because everyone is trying to avoid learning how to actually install the pieces of software (once), and their magic (free) black boxes are going away?
I recommend VS Code remote connections and docker builds via the docker extension to do rapid build-run-redo. Remember to make sure it works from scratch each time. You can automate them with Jenkins... (which came first, the Jenkins or the Jenkins Docker image?)
I also recommend Platform One. (you'll need a smart card)
I also recommend reading the particular software's documentation ;)
Thats super silly, it's so easy to make docker images... especially if you have a fast connection you can build a proper image which is production ready in a few hours.. (eg.30-40 builds)
Not OP, but in general the process goes like this:
- you pick a base image you want to use, like Alpine (small size, good security, sometimes compatibility issues) or Debian or Ubuntu LTS (medium size, okay security, good compatibility) or whatever you please
- if you want a common base image for whatever you're building, you can add some tools on top of it, configuration, CAs or maybe use a specific shell; not a must but can be nice to have and leads to layer reuse
- you build the image like you would any other, upload it wherever you please (be it Docker Hub, another registry, possibly something self-hosted like Sonatype Nexus): docker build -t "my-registry.com/base/ubuntu" -f "ubuntu.Dockerfile" . && docker push "my-registry.com/base/ubuntu"
- then, when you're building something more specific, like a Python or JDK image or whatever, you base it on the common image, like: FROM my-registry.com/base/ubuntu
- the same applies not just for language tooling and runtimes, but also for software like databases and key value stores and so on, albeit you'll need to figure out how to configure them better
- as for any software you want to build, you also base it on your common images then
Example of cleanly installing some packages on Ubuntu LTS (in this case, also doing package upgrades in the base image) when building the base image, without the package caches left over:
In general, you'll want any common base images to be as slim as possible, but on the other hand unless you're a bank having some tools for debugging are nice to have, in case you ever need to connect to the containers directly. In the end, it might look a bit like this:
upstream image --> your own common base image --> your own PostgreSQL image
upstream image --> your own common base image --> your own OpenJDK image --> your own Java application image
In general, building container images like this will lead to bigger file sizes than grabbing an upstream image (e.g. eclipse-temurin:21-jdk-noble) but layer reuse will make this a bit less of an issue (if you have the same server running multiple images) and also it can be very nice to know what's in your images and have them be built in fairly straightforwards ways. Ofc you can make it way more advanced if you need to.
In brief you need to switch the registry from (iirc) docker.io/bitnami to docker.io/bitnamilegacy. Note that as of iirc tomorrow those images will no longer be updated. So the moment there is a high or critical cve you better have a plan to use a new image and likely helm chart or send broadcom cash. The old registry will continue to have a "latest" tag but this should not be used for production.
Anyone know what happens to their Helm charts? As far as I know they remain available but do they work with non-Bitnami images? Can I use the official redis image instead of bitnami/redis with the Bitnami redis chart for example?
Q: What will happen to the existing OCI Helm charts?
A: The already packaged Helm charts will remain available at docker.io/bitnamicharts as OCI artifacts, but they will no longer receive updates. Deploying these charts will not work out-of-the-box unless you override the bundled images with valid ones.
*except for the BSI images included in the free community-tier subset.
That’s the first part, but will the charts work if I override the image name with a non-Bitnami one (e.g. docker.io/library/redis for redis)? Or do they bake in special stuff in their images that their charts rely on?
You need the images that go with the charts. They have their own config system, which usually involves elaborate shell scripts in the images that receives parameters from the chart.
Maybe they're still counting back ports as CVEs? (Seems like scanning software still always false positives on a listening port that flags for a version and doesn't take into account backport and doesn't actually test for the CVE/vuln-- it's so exasperating weeding through reports thrown at you by "Security")
But yeah seems unlikely that official Debian images would be full of CVEs unless they are not being regularly updated.
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.
I concur. There was supposedly a migration path from their postgresql image & chart to the postgresql-ha image & chart.
Aside of having to re-mount the data disk and move things around manually; the -ha chart has numerous other issues where it always requires the master to be node-0. And with pods being rescheduled within a statefulset, good look having the master be on node-0. If there was an outage and the master is anywhere else, node-0 will just 'wait' for a master to come online, time out and shoot itself in the head thinking it is in a network partition and that retrying may help.
The algorithm implemented by postgresql-ha turned out to be plain broken. Only able to survive pods neatly shutting down.
Sometimes, over engineered approaches are necessary to make older software work with environment variables and configmaps, because said software is still designed for traditional VM deployments.
I understand the vision behind trying to monetize these images for enterprise use, and can get down with the idea of maintaining both a “less secure but free” and “more secure but paid” model. But it appears that Broadcom’s intent is to over time force everything on to their enterprise offerings, which seems like a short sighted thing to do.
Over time it will limit adoption and ultimately just make everyone go back to the native open source offering, cutting bitnami/Broadcom out of the loop.
Broadcom really took the open source community backwards with this move IMO.
24 hours? Wouldn’t it be better to do shorter bouts of scheduled unavailability so unknowing people’s systems will boot up without manual intervention, but still generate lots of nasty logs / alerts?
I thought the opposite: 24h seems too brief to me, since many of their images are typically for long running servers, some people will receive a painful heads up only next year or later when their K8s pod gets scheduled to a new machine, requiring a (failing) pull.
I'm glad this was top of Hacker News because I hadn't heard about this until now, and we'd only have found out once deployments started failing.
It's not always a 5 minute job to switch to a different image with different configuration and retooling required.
Fortunately, I started moving us away from Bitnami a little while ago because they started giving me the ick some time back, but a few stragglers remain.
Their Dockerfiles include things like download pre built binaries from $SECRET_BASEURL which is hosted by them, can still be found in git log though. I imagine it will go offline / have auth soon enough.
I've been thinking a lot about this kind of thing recently - and put a prototype up of htvend [1] that allows you to archive out dependencies during an image build. The idea being that if you have a mix of private/public dependencies that the upstream dependencies can be saved off locally as blobs allowing your build process to be able to be re-run in the future, even if the upstream assets become unavailable (as appears to be the case here).
Or if you have a decent sized deployment in one of the clouds, it's extremely likely you'll already use their internal registry (eg AWS ECR). I know that we do. So it's just a case of setting up a few docker build projects in git that push to your own internal registry.
It is at the top of the announcement. This only affects OCI images, not source code "The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license."
> The Photon images provide many other benefits not previously available to users of Debian images, including:
Drastically reduced CVE count (e.g., 100+ CVEs to in some cases 0)
This implies that they are deliberately offering Debian images with known unfixed security vulnerabilities. Sounds evil.
> 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.
[1]: https://operatorframework.io/operator-capabilities/
> 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"
Aye, It's a bit like saying you can't sell your code, because you wrote it in someone elses software.
Writing a decent Dockerfile isn't hard, and keeping it maintained and working with new versions is still work and it's past the wheelhouse of very many people. It's entirely reasonable to want paid for that effort.
That said, it's not work I personally value enough to put my hand in my pocket, and that's a fair take too.
I think it's perfectly fair for them to say "we're not doing this any more". The sketchy part is deleting the public registry at docker.io/bitnami rather than just no longer updating it. Why can't docker.io/bitnami become the 'legacy' registry, receive no future updates, so at least folks who don't hear this news won't have pulls suddenly fail?
edit: like if I have a package on NPM and I want to stop offering it, I think it's shitty to just delete it. That breaks builds.
Vendor lock-in is a thing. Switching costs are a thing. They know this. That's the whole business model. They're expecting that the cost of switching to outweigh the cost of the subscription.
I get that this business model is fashionable amongst wannabe rent-seekers, but it's still antisocial and should be shunned.
This is not rent-seeking: Rent-seeking is leveraging your position to garner economic rents, like putting a toll gate across a highway in which the only value received for the toll is the opening of the gate.
Rent-seeking would be Broadcom saying that you must run a Bitnami image in CloudFoundry or pay a penalty for not doing so. They are in fact doing some work here. We may disagree on whether or not they're being compensated fairly for that work, but that disagreement doesn't turn this into "rent-seeking"
The penalty is the work of migrating away and redoing any integration work on a month's notice. That might seem trivial to a small deployment, but I know some people that use these images everywhere, including in places that aren't immediately obvious.
Not to mention a lot of people that are going do be doing this work are the same people also spending the year swapping out hypervisors which is also no small task.
Maybe it's just me?
Evaluating the risks of vendor lock-in is a buyer's task, unless it is a protected market or there is a monopoly abuse involved.
In this case, nobody forced (generic) you to use Bitnami's Docker images, you probably just thought "how convenient, always updated and easy to pull, one less thing to worry about". Which is fine, but it's always a bet on what will happen in the future.
Yes, yes. And a person who's pick-pocketed may well do better to protect their pockets. This does not absolve the thief.
Reasonable people can disagree about the degree to which vendor lock-in is antisocial or the degree to which there even is vendor lock-in here. But telling victims of such behavior to just suck it up and price it in only serves to distract from and abet actors abusing positions of power to rent seek and create low trust environments. It's not a systemic solution and it's not a serious engagement with the criticism levied.
> Yes, yes. And a person who's pick-pocketed may well do better to protect their pockets. This does not absolve the thief.
Freedom of roaming without having to worry about pickpockets it's one thing. Deciding that you go with the opensource offering of a company because it's convenient for you is another. I know it's just one example but the entitlement here is _the key_. You are entitled to go to whatever zone of a city and it's not right to blame the victim in that case. You are not entitled to have part of the business decisions of a company you were a "client" without paying a dime or signing any binding contract. You would be entitled to that if they were breaking some opensource license, for example.
Just because you want that to be "the key" doesn't make it so. You make that your singular focus and you let antisocial behaviour off the hook. That is your prerogative.
For me, the key is the bait and switch. It's like a drug dealer offering first time customers a discount. It's a good business strategy to get people hooked. Very enterprising. Nonetheless, I would prefer a society without such behaviour.
When a project is abandoned, when updates are slow, when features people want are not being released, when tracking upstream dependency updates are delayed, sure, you are not entitled to anything and I’ll be the first one to say get off your butt and contribute. In the other hand when you engage with the community for years under an OSS/free context then once the community has invested in your project, learning it, creating learning resources for it, integrating it into their own projects, and you never communicated your intention to “wait until it gets big then then pull the rug” it feels like a disingenuous bait and switch. The reason it feels that way is because it is a disingenuous bait and switch. This is even more so the case when you built your project on top of other projects.
I have no problem using a paid product or service or paying for support on a OSS product, but will never pay one of these bait and switch scams a dime, no matter how much engineering effort it takes.
It’s Broadcom. Don’t use anything from them unless you can’t avoid it.
Same applies to Oracle.
I understand the sentiment and where it comes from, and I'm not saying it's a good decision from Broadcom (I think it is a bad one indeed!). But still, this risk is part of the game. Even if it was full opensource and with a broad community, it was still a single vendor, not even a non-profit umbrella like the Apache or Linux Foundation. So, the risk of trusting a single vendor was there.
The good thing of it being opensource is that someone else (company, community, foundation or whatever) can step in, fork it, and maintain it from now on, unlike what happens with proprietary software or SaaS.
> it's extortion
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.
What do you mean, that's the business model more than half the VC-funded startups now. Provide something for free or near free, wait until your customer is dependent on you and/or consolidate into at least an oligopoly and then put the thumbscrews on.
I find that to be a pretty dishonest business model. I don't have any Bitnami images to replace, but I know a lot of people who do without ever having made that choice - and their bosses aren't going to pay Broadcom for the most part either. So you end up with overworked developers that now hate Broadcom and/or a whole lot of deployments that just break or never get updated. The number of people going "I can just switch over to the archive image, whatever" on the K8s subreddit alone is concerning.
The Bitnami images and helm charts are just convenient repackaging of things that are already freely (gratis) available. There's nothing stopping you from still deploying Kafka or Redis, etc. into your k8s cluster without using the Bitnami helm chart or building your own charts.
I think that's the point of above of "now you have to do your job" There's an evaluation that takes place when choosing to use something as an engineer, and the writing should have been on the wall the moment that Broadcom bought Bitrock to start planning to reduce dependency on those things.
> What do you mean, that's the business model more than half the VC-funded startups now. Provide something for free or near free, wait until your customer is dependent on you and/or consolidate into at least an oligopoly and then put the thumbscrews on.
You skipped the part where you bankrupt your competition in the space who can't afford to hemorrhage cash they don't have like a VC-backed startup can, hoover up all the customers, then charge more than the old guard industry did in the first damn place for a worse version of the same service, while also paradoxically paying any workers needed to provide said service even less than they were making before.
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.
The problem I think is that all the easy infrastructure problems have been solved and the market is crowded with those solutions. Solving the hard problems is probably where you could have a viable business but I don't really see that many companies trying to solve those:
* Making mono-repos work for large companies.
* Mixed language builds are still a ci/cd unsolved problems for most companies.
* Testing strategies for Iac deployments.
And more that I won't bother to list here.
This would make a great blog post: high hanging fruit of digital infrastructure
The outcomes of this behavior will be devastating and the problems will last for generations.
Most of these companies and technologies won't last that long.
Software generations are measured in months, maybe that's what they meant?
Why?
Asking the billion dollar questions I see.
> Previously, you would prioritize traction among developers over focusing on revenue.
A.k.a. using open source as a marketing tactic to lure in customers, only to do a rug pull once the business gains enough momentum.
> But that does not work in 2025.
Good. It is an insidious practice. There are very few projects that actually do this properly without turning their backs on the users who made their products popular in the first place.
> 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.
The strategy of delivering valuable products that benefit users without exploiting them has always existed. The thing is that many companies choose the greedy and user hostile path, instead of running a sustainable business that delivers value to humanity and not just to shareholders, which is much more difficult. So I have no sympathy towards these companies.
You're not wrong. They add miniscule value. But what does that say about the people using these images who are now struggling to replace them?
You can't have it both ways.
If their value-add was miniscule then they should be trivial to replace.
If it's a struggle to replace them then that's the value they were adding.
No, the struggle is fully manufactured by this rug pull. If I had known this was going to happen when I was setting up my infra I could've used any number of other alternatives, including just building them myself, at little to no extra effort. Now I have to waste time migrating off of these.
You did know this was going to happen, and chose to pretend you didn't.
We also know the Sun is going to swallow the Earth and eventually burn up. That doesn't mean we stop building with what we have now.
Packaging is not miniscule value, it's valuable gruntwork.
A lot of work that apparently is not valued enough to justify paying for.
You could make the same argument against Linux, openssl, ffmpeg, compression algorithms, web browsers and so many more things.
A select few will pay for the rest of us, but it's valuable to everyone who uses it.
Broadcom just wants to squeeze anyone who can't do it themselves.
The problem isn't paying for it, it's the extra workload of retrofitting authentication to all your things. I'd find this a lot more enticing if they just made you set a "i have a license or i am evaluating or i am not commercial" flag in Helm or fail the build. Plus the cost is extremely disproportionate, but some will pay it given the one month deadline.
it doesn't say anything nice that "moderate inconvenience" is a "struggle"
I think this is now the Broadcom way !
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.
Maybe the community can repackage it since Bitnami is only packaging.
Naive take.
That's like saying, "Honda isn't a car company, they're an assembly company because they don't mine the minerals to make the parts and rely instead on supply chains"
Well, Bitnami didn't produce own hardware stack either ;) Joke aside, it's not naive - CentOS, Alma, Rocky, Ubuntu... FOSS community has some experience with these things
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.
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.
This has to be a joke, right? Months of effort for a makefile? In which world do people live these days
You seriously underestimate this in general case. Build system may be made in weeks, but is polished in months or even years, to account for all the different usage and environment scenarios. Otherwise, it's typically very fragile.
Which is why I think you should not try to build generic images like this. I looked at the source and it seems like s lot of work had been put into creating a fragile mess.
After having been burned several times by images I prefer writing my docker images from scratch (based on the Debian or Alpine images) for production systems. I only use ready-made images for quickly getting something running locally to evaluate it.
I don't even see any tests in the bitnami repo?
Wasn't the point of the post you replied to that it isn't just a simple makefile ? That repo contains quite a lot carefully assembled scripts for each image that handles a lot of corner cases.
In the world where "developers" cannot even wipe their buttocks without AI.
Tell me you haven't ever written even a moderately complex Makefile without telling me you haven't ever written even a moderately complex Makefile.
It would only take you a weekend!
It is a lot of work but it is work that for the most part should not have been done. I took a quick look at the code (since I know PG very well) and I would not recommend anyone to use that mess off Bash code which configures PostgreSQL in an annoying and incorrect way and exposed some arbitrarily select settings in the environment (some very rarely used) while you have to do most in the config file. Better to just write your own Docker image for scratch, or use the official PG image of your needs are simple.
This is what happens if you merge every feature request you get and do not have a clear plan or architecture. After reading the code I am happy they are deleting the images, at least if this one is typical.
As a PostgreSQL expert I can write a much better image which suits my needs in one day, which I have also done several times. It would be harder for a non-expery but I do not think a non-expert should use this image due to some footguns I spotted. This kind of generic image is a bad idea and very hard to build.
> but I do not think a non-expert should use this image due to some footguns I spotted
Could you elaborate on your findings?
Hindsight is 2020, there’s now helm/kubernetes operator under the cloud native umbrella. I’m sure they took in all the mistakes from here. This helm chart is getting long in the tooth, but is still monumental. Imo running psql on kube is a mistake to begin with but here we are.
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.
They do keep some of them more up to date, for example the bitnami python image had system packages patched faster than the official one. But if you are willing to pay then chainguard is a better solution.
ChainGuard is $$$$$$$
We talked to them a couple years ago. A lot of what they are doing besides Wolfi is using Alpine which removes alot of findings by default
Alpine helps but it's not perfect. Plenty of outdated packages with known CVEs there for long time.
Often they are not exploitable but it's easier to pay chainguard to have a constant zero on our vuln scanner than to deal with distroless builds ourselves.
The GPU images are indeed very expensive though.
I get it but the likelihood those vulns are exploitable in your environment is dubious. It’s a lot of compliance theater. Defense in depth
I agree, but I'm not spending my time arguing with PCI auditors.
Also it's safer from supply chain attacks. Malware inserted via compromised docker hub tokens is a growing threat.
Constantly updating to the latest version of innumerable software projects is safer from supply chain attacks? :)
My experience has been that the cost of “patching” is often bugs and instability, having gained nothing security-wise.
Right, I deal with NIST 800-53 based things where we have heavy albeit manual auditing. We pull from Iron Bank mostly but also employ Nexus Firewall. People can’t pull direct Docker Hub.
For what it's worth, their pricing has decreased substantially over the last year. Their most recent quote to us was about 25% of the one we received a year or so ago.
For some more transparency, we pay ~$9k/year per image (all versions/variants) for some basic images (think python, golang etc). The ones with cuda drivers are more expensive but I don't have the exact prices on hand.
Some other open source projects have also shipped Bitnami software in their own helm charts, i.e. APISIX's etcd instance is the Bitnami chart pulled in as a dependency.
Not that it ever worked well, we had to scale it to 1 because the quorum would constantly break into unrecoverable states.
Between the VMware licensing changes and this, it looks like Broadcom is making a serious play at dethroning Oracle as the most evil software vendor.
It's a shame that competition for this position has been ramping up lately.
I'm still waiting to see how Broadcom will monetize the Spring ecosystem - which is widely used in almost all large enterprises.
Sadly, it feels like an inevitability at this point.
Good lord, I didn't know their tentacles were that deep. VMware sure had a lot of touch points.
My team is worried about that too. We've been a java and spring shop for years. We're looking at micronaut, it's similar enough.
When I had someone from another team take a look at broadcom and what they could do to spring, they said the licenses are permissive, it will be fine. Likely not that simple.
My guess will be:
- Shorter support windows, with longer support available for purchase (VMWare actually introduced this, but Broadcom can weaponize it)
- Then Enterprise Spring, which has additional features
- Then some other license shenaningans.
Hazelcast recently made the move where CVE security updates are only released into the OSS ecosystem quarterly - whereas the enterprise model gets them as soon as they're ready. In OSS, you have to rebuild and patch yourself.
That's a special kind of evil, which has Broadcom DNA all over it.
Yes, same here. Wonder how they will try to monetize it.
That's probability of 1.0, the missing question is when.
Holy shit, Broadcom owns Spring? Yikes.
They're still technically Avago Technologies, just wearing the name of Broadcom after the acquisition in 2015-2016. Not sure if there's much of Broadcom left, beyond the name and what IP they had at the time which was not sold off, like they did with the IoT related IPs.
This is much less exciting once you realize how evil broadcom is. Still, I suppose we all win in the short term.
I am certain most of Bitnami's engineers don't agree with those decisions.
Taking a bunch of projects and making containers and flexible helm charts for them is kind of an interesting model. It’s what Redhat and Canonical do with raw Linux packages; they charge for premium support and even patches or extended support.
I was going through one of my clusters, I have two bitnami uses and they are both ‘building blocks’ I use Trino, which uses a metastore which uses postgresql and then some other package uses redis. It seems like both postgresql and redis could/would have containers and charts to install their stuff, where it breaks is the postgresql guys probably want to support “current” and not 4 major releases back, which is kind of normal to see in the wild.
It is kind of an interesting model, I’d love it if rancher or openshift or someone started to seriously compete. Shipping a Kubernetes in a box is nice but if they started packaging up the building blocks, that’s huge too.
I won't be so sure about that. Bitnami's installer was always proprietary software.
Microsoft's existence means they're all fighting for 2nd place.
Broadcom has always been about pure evil (cough capitalism cough), you just haven't been affected by it before. Ask anyone who's worked with their hardware... So
So, are they evil because they decided to stop sponsoring free network egress?
Others have already provided good answers. I wouldn't classify it as evil if all they did was to stop maintaining the images & charts, I recognise how much time, effort and money that takes. Companies and open source developers alike are free to say "We can no longer work on this".
The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
I know Broadcom inherited Bitnami as part of an acquisition and legally have no obligation to do anything, but ethically (which is why they are evil, not necessarily criminal) they absolutely have a duty to minimise the damage, which is 100% within their power & budget as others have pointed out.
And this is before you even consider all the work unpaid contributors have put into Bitnami over the years (myself included).
It's also entirely fine if they delete these images to me. But not with a week of time frame, as originally intended.
And sure, we can go ahead and discuss how this being free incurs no SLAs or guarantees. That's correct, but does not mean that such a short time frame is both rude and not a high quality of offering a service. If I look at how long it would take us to cancel a customer contract and off-board those...
And apparently it costs $9 to host this for another month? Sheesh.
If your doing anything serious you should have artifactory setup.
> The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
Something, something, sticking your hand in a lawnmower and expecting it not to be cut off.
Broadcom is second only to Oracle.
would you mind getting in your time machine and telling me this before broadcomm acquired bitnami?
that's an assumption, but Broadcom is most likely using open source software in all of their apps. So they do have a moral to also give something back. So just saying it's fair that they don't want to provide something for free anymore isn't really all that fair.
Oh don't get me wrong, my claim is that they are not even clearing the absolute lowest bar when it comes to their stewardship of the Bitnami repositories: Do no harm.
Expecting moral behavior from Hock Tan isn’t likely to pan out.
The images are currently in Docker Hub. If $9/month (or $15, not 100% sure if $9 includes organizations) to keep those images available is too much for Bitnami I'm sure there are many organizations who wouldn't mind paying that bill for them (possibly even Docker Hub itself).
Broadcom is deciding to host it on their own registry and bear the associated cost of doing so. Not sure what this has to do with sponsoring network egress
Does said network egress cost $50k per user?
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.
100% agreed. I don’t understand the point of throwing all conventions out the window and building their own brittle scripts on top of it. All their images require docs to configure because none of the upstream documentation applies.
I've used them as a quick way to get rootless configured base images. Not sure if official repos provide those now, but it used to be a big hassle to get things like postgres images running without root in their containers. Although I often had to read through their dockerfiles to figure out the uid setup, where configs live, etc because they were not consistent between the various bitnami images.
Back in the day, Bitnami was a way to run Wordpress on Windows. They packaged it nicely so that you could install it on Windows Server. Nowdays that could get you fired, but back then Linux was not so widespread.
What are some resources for these conventions? As far as I can tell everyone else rolls their own bespoke images based off of of a projects image in order to customize the configuration.
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"
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?
Nope - we're early stage so we're really flexible not just on pricing but licensing terms too. We have many customers that are smaller startups, not just typical F500 types.
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...
1: https://edu.chainguard.dev/chainguard/chainguard-images/chai...
It's on the roadmap :)
It's a good feature, just hasn't been prioritized so far because customers haven't really had trouble with the current basic approach.
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.
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.
Hmmmm, I'm not sure that's how it would be read. If there's any 'associated commercial activity', it falls under the CSR, even if the images themselves are free and open source.
(That said, the overhead of the CSR is really not much, from what I can tell. It's pretty lightweight as EU standards go)
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.
Just to be crystal clear about the open source part: the code for all container images will continue to be maintained, kept up to date, and publicly accessible on GitHub (https://github.com/bitnami/containers) under the Apache 2 license.
What Bitnami is discontinuing is the publishing of prebuilt images to public registries. However, the build code remains available, so users can still build the images themselves and push them to their own registries by running a couple of commands.
Snooping around, it seems the license costs $50K+ annually. I'm not their target market. ;)
From TFA
> BSI is effectively democratizing security and compliance for open source so that it doesn’t require million-dollar contracts from vendors with sky-high valuations.
I suppose 50k isn't a million dollar contract, but it's certainly also not "democratizing" anything
Depending on your needs, this could be a bargain as advertised. It's only expensive relative to what you can build on your own, or what competitors offer.
It's a bit tricky to work through all the jargon, but it's my understanding that they are simply pulling the mass of things that they provide for free. You can still get the Docker files for their offerings (not sure they offer all tags though?") and you can even use the images from Docker Hub.
But. What they are offering is considered "development" regardless of what you are using it for? In other words, NOT a production environment, because they aren't giving you a production environment (or at least what they define as a production environment.) What they give you for free is the "latest" and on a Debian system.
What they offer as "secure" is running on Photon OS and goes through a security pipeline, etc. They aren't holding anything back aside from the services they provide.
The easiest strategy to be profitable as biz without acquiring new users base, lol :P
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.
Understandable.
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.
Because "bitnami" has brand value. It makes business sense to reuse the name for the new service you are trying to sell.
Any brand value that bitnami has will be entirely destroyed by this incomprehensible change. People will associate the ‘bitnami’ namespace with “can’t possible utilize for long term production use”
> It is sad to see how Broadcom cannot do padding right for mobile…
It's on brand when you consider how badly the styling in Rally needs an update.
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 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?
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)
Almost the same situation here. The only thing I used was Kafka, and I only used that to allow horizontal scaling of Argo Events sensors. Moved over to jetstream, saved a bunch of compute and memory, and realized I didn't need to scale Argo's sensors horizontally. Really, Bitnami's decision made my life easier in the end.
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.
The list of images for the first brownout: external-dns, Kafka, Memcached, WordPress, Grafana, Cassandra, Prometheus, OpenLDAP, Thanos, Python.
Thanks for mentioning these! Do you know what are the official channels they're doing the announcements in? In the post they just mention the word "usual" with no clarification.
https://github.com/bitnami/containers/issues/83267
I.e https://github.com/bitnami/containers/issues/83267#issuecomm...
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.
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.
I believe Guix also borrowed[1,2] the bootstrap chain[3,4,5] written by Jeremiah Orians, same as you did.
[1] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
[2] https://www.gnu.org/software/mes/
[3] https://bootstrapping.miraheze.org/wiki/Stage0
[4] https://savannah.nongnu.org/projects/stage0/
[5] https://github.com/oriansj/bootstrap-seeds
Is "brownout" a common or standard term in the industry? First time I see it.
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.
1: https://developerhelp.microchip.com/xwiki/bin/view/products/...
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)
have also heard this as doing a “scream test” — turn it off, see who screams about it
Yes, another example of brownout at https://spring.io/blog/2022/12/14/notice-of-permissions-chan... It is probably the only way to warn users when you do not know the contact info.
There was actually a really terrible brown-out by Poetry (a Python dependency management and packaging tool) where they introduced sporadic failures to people's CI/CD systems: https://github.com/python-poetry/poetry/pull/6297
Yes I heard of GitHub doing it I think
You intentionally break something just a little to force dependents to notice, before turning it off completely
First heard about this when docker started rate limiting
Yes.
It refers to a situation where a system is deliberately designed to fail (usually for short periods of time), to still provide some level of service while alerting others that the system is soon to be turned off.
Yes. Going from green to red is called “browning out”.
That is not where the term comes from. Lights out -> Blackout (WWII, to stop overflying aircraft from having easy targets and to disrupt navigation). Reduced voltage on the grid -> lights go from white to orange and eventually to brown, not quite a blackout -> brown out.
The word seems to slightly predate WWII.
The OED reports that the disrupted-electrical supply sense of blackout was first used in 1934; the air-defence one (no light) in 1935. However, the OG use seems to be in the theatre, where the lights are shut off during set changes (1913, probably earlier).
Brownout does seem to be a WWII-era term, but more related to conservation/shortages than air defence.
Is that the origin?
I thought it was an analogy to the electrical problem: flickering lights due to high demand.
Don't know the origin, but with no technical background past using Linux, I only ever heard of brownouts in contexts of failing (often 3rd world) electrical infrastructure. Mostly Africa and South America (don't mean to offend anybody living there, I know they're vast continents with many rich/infrastructure-stable countries too).
Very odd to call it a 3rd world phenomenon when California calls it a normal day.
Origin is the electrical grid overload which caused incandescent lights to literally "brown out", as has been mentioned here.
Later is was coopted to mean any problems with power supply not including outright drop to zero-zero/disconnections. cf microcontroller brown-out handling, also mentioned above.
Then later it seems it was generalized to mean sort-of-non-terminal problem with supply of most anything.
Website got hugged to death: https://archive.is/plsp9
A shame that the docker.io registry is not immutable and allows deletion. I think many people are unaware images from that registry can break anytime.
I visited Bitnami in San Francisco in 2017, still have a hoody.
Broadcom is a rat.
Is anybody familiar with the differences between the new Bitnami Secure Images compared to images from, say, Chainguard?
IronBank is free though more DoD focused
“If you’re looking to deploy multiple images, Chainguard’s per-image charges could quickly exceed Bitnami’s flat subscription cost. For example, licensing 3 images at $30K each would already reach $90K/year.” via Reddit.
There is a new Catalog option. Their pricing is “custom” and not published online so all we have is Reddit anecdotes like here
https://www.reddit.com/r/cybersecurity/comments/1ihy9sr/chai...
Is anyone working on mirroring the images and keeping them updated?
Updating the Bitnami images is probably a bit of a challenge. From looking at them last year, I believe that they are build around a Bitnami style/framework. They are confusing at best.
If you're Bitnami it probably made sense to do it the image the way they did, but for everyone else, it's just a massive complication.
Personally I don't understand why anyone would have opted to use the Bitnami images for most things. They are really large and complex images and in most cases you'd probably be better of building your own images instead.
My guess is that there's a very small overlap between people who want to maintain Docker images, and the people who chose to run Bitnamis images.
The Docker images are complex for the sake of the Helm charts, which sometimes need to pass down tons of parameters
These aren't just for your laptop, they're supposed to be able to run in prod
I'm still stuck with 3 bitnami charts that I keep updated by building from source, which includes also building the images, all on our private registry.
That makes some sense. I've only used Bitnami images with Docker compose or as standalone containers. In those case you're frequently better of just mounting in a configuration file, but that won't really work in Kubernetes.
I would argue that if you run Kubernetes, then you frequently already have the resource to maintain your own images.
You'd also have to maintain the helm chart, which is arguably far more work.
If you don't need the bitnami helm chart functionality, using more stock container images is easy and preferable.
I had not used bitnami images for.. probably 5 years at this point and they always seemed servicable in a pinch, usually used for testing and I when I brought this up recently I was also told (by k8s users) that the helm stuff is probably what actually has most people up in arms because it is very common. We're the minority who remember bitnami as a non-critical choice among many.
> Personally I don't understand why anyone would have opted to use the Bitnami images for most things.
At my previous company, we used it because of the low CVE counts. We needed to report the CVE count for every Docker image we used every month, so most of the images were from Bitnami.
There are many enterprise companies freeloading on Bitnami images, and I’m surprised it took Broadcom this long to make this change.
That only works for weeks or so, since they won't be updated, according to the PR.
It's time to build your own from core / foundational images - something I recently learned and now seek to master.
Would you kindly share how to do it?
Wait... this whole time reading this thread, I'm racking my brain for what bitnami provided (I used to use them before docker came around. I never would have got Redmine up and going without them -- the install seemed so foreign.) that building a docker image couldn't, because surely everyone knows how to build one from scratch, right?... right?
Is all the panic because everyone is trying to avoid learning how to actually install the pieces of software (once), and their magic (free) black boxes are going away?
I recommend VS Code remote connections and docker builds via the docker extension to do rapid build-run-redo. Remember to make sure it works from scratch each time. You can automate them with Jenkins... (which came first, the Jenkins or the Jenkins Docker image?) I also recommend Platform One. (you'll need a smart card) I also recommend reading the particular software's documentation ;)
Thats super silly, it's so easy to make docker images... especially if you have a fast connection you can build a proper image which is production ready in a few hours.. (eg.30-40 builds)
To add, it's really satisfying to build your own, push it and host it on your own internal repo that anyone in your group can use.
"Just go get the DEV image, Josh."
Not OP, but in general the process goes like this:
Example of cleanly installing some packages on Ubuntu LTS (in this case, also doing package upgrades in the base image) when building the base image, without the package caches left over: In general, you'll want any common base images to be as slim as possible, but on the other hand unless you're a bank having some tools for debugging are nice to have, in case you ever need to connect to the containers directly. In the end, it might look a bit like this: In general, building container images like this will lead to bigger file sizes than grabbing an upstream image (e.g. eclipse-temurin:21-jdk-noble) but layer reuse will make this a bit less of an issue (if you have the same server running multiple images) and also it can be very nice to know what's in your images and have them be built in fairly straightforwards ways. Ofc you can make it way more advanced if you need to.In brief you need to switch the registry from (iirc) docker.io/bitnami to docker.io/bitnamilegacy. Note that as of iirc tomorrow those images will no longer be updated. So the moment there is a high or critical cve you better have a plan to use a new image and likely helm chart or send broadcom cash. The old registry will continue to have a "latest" tag but this should not be used for production.
According to the article the current situation already is a bit of a clusterfuck:
The Photon images provide many other benefits not previously available to users of Debian images, including:
Anyone know what happens to their Helm charts? As far as I know they remain available but do they work with non-Bitnami images? Can I use the official redis image instead of bitnami/redis with the Bitnami redis chart for example?
This is covered in the official GitHub issue: https://github.com/bitnami/charts/issues/35164
Q: What will happen to the existing OCI Helm charts? A: The already packaged Helm charts will remain available at docker.io/bitnamicharts as OCI artifacts, but they will no longer receive updates. Deploying these charts will not work out-of-the-box unless you override the bundled images with valid ones. *except for the BSI images included in the free community-tier subset.
That’s the first part, but will the charts work if I override the image name with a non-Bitnami one (e.g. docker.io/library/redis for redis)? Or do they bake in special stuff in their images that their charts rely on?
You need the images that go with the charts. They have their own config system, which usually involves elaborate shell scripts in the images that receives parameters from the chart.
It is hard to tell if it will work or not. Just need to compare the image and test the override out.
This is such a weird state.
> The Photon images provide many other benefits not previously available to users of Debian images, including:
> Drastically reduced CVE count (e.g., 100+ CVEs to in some cases 0)
How can Debian image contain 100+ CVEs? It's nonsense. Surely Debian is as secure as most other "commercial" distros.
This CVE scanning stuff is clear FUD to promote commercial distros.
Maybe they're still counting back ports as CVEs? (Seems like scanning software still always false positives on a listening port that flags for a version and doesn't take into account backport and doesn't actually test for the CVE/vuln-- it's so exasperating weeding through reports thrown at you by "Security")
But yeah seems unlikely that official Debian images would be full of CVEs unless they are not being regularly updated.
Bitnami K8s helm charts was very well done but overall we can live without them.
I would suggest boradcom to offer two tie: one free on they repository and one se t of more specific images.
Burning the docker.io images is a dumb move.
I long advocated for a proper mirror and archive of the docker hub.
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.
I concur. There was supposedly a migration path from their postgresql image & chart to the postgresql-ha image & chart.
Aside of having to re-mount the data disk and move things around manually; the -ha chart has numerous other issues where it always requires the master to be node-0. And with pods being rescheduled within a statefulset, good look having the master be on node-0. If there was an outage and the master is anywhere else, node-0 will just 'wait' for a master to come online, time out and shoot itself in the head thinking it is in a network partition and that retrying may help.
The algorithm implemented by postgresql-ha turned out to be plain broken. Only able to survive pods neatly shutting down.
Sometimes, over engineered approaches are necessary to make older software work with environment variables and configmaps, because said software is still designed for traditional VM deployments.
Agreed, Bitnami images often feel over-engineered.
This is great new for me. I've always disliked bitnami's busy file layouts and other weird preferences.
I understand the vision behind trying to monetize these images for enterprise use, and can get down with the idea of maintaining both a “less secure but free” and “more secure but paid” model. But it appears that Broadcom’s intent is to over time force everything on to their enterprise offerings, which seems like a short sighted thing to do.
Over time it will limit adoption and ultimately just make everyone go back to the native open source offering, cutting bitnami/Broadcom out of the loop.
Broadcom really took the open source community backwards with this move IMO.
24 hours? Wouldn’t it be better to do shorter bouts of scheduled unavailability so unknowing people’s systems will boot up without manual intervention, but still generate lots of nasty logs / alerts?
I thought the opposite: 24h seems too brief to me, since many of their images are typically for long running servers, some people will receive a painful heads up only next year or later when their K8s pod gets scheduled to a new machine, requiring a (failing) pull.
I'm glad this was top of Hacker News because I hadn't heard about this until now, and we'd only have found out once deployments started failing.
It's not always a 5 minute job to switch to a different image with different configuration and retooling required.
Fortunately, I started moving us away from Bitnami a little while ago because they started giving me the ick some time back, but a few stragglers remain.
If I had to hazard a guess, it's so the downtime is noticed across various different timezones.
Will any source to build new images remain available without subscription?
They write in the press release, that the sources remain under Apache 2 license, they just stop distributing prebuilt images for free.
Edit: As I see it's true.
Source code for OCI images: https://github.com/bitnami/containers/tree/main/bitnami
Charts: https://github.com/bitnami/charts/tree/main/bitnami
> Source code for OCI images: https://github.com/bitnami/containers/tree/main/bitnami
If you look at the folders there, you'll see that all of the older Dockerfiles have been removed, even for versions of software that are not EOL.
For example:
PostgreSQL 13 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 14 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 15 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 16 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 17 (present): https://github.com/bitnami/containers/tree/main/bitnami/post...
> The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license.
Ofc they're all still in the Git history: https://github.com/bitnami/containers/commit/7651d48119a1f3f... but they must have a very interesting interpretation of what available means then.
It looks like setting up a mirror and CI/CD on top of Github might work for some time. ghcr is free for public images
Their Dockerfiles include things like download pre built binaries from $SECRET_BASEURL which is hosted by them, can still be found in git log though. I imagine it will go offline / have auth soon enough.
I've been thinking a lot about this kind of thing recently - and put a prototype up of htvend [1] that allows you to archive out dependencies during an image build. The idea being that if you have a mix of private/public dependencies that the upstream dependencies can be saved off locally as blobs allowing your build process to be able to be re-run in the future, even if the upstream assets become unavailable (as appears to be the case here).
[1] https://github.com/continusec/htvend
Or if you have a decent sized deployment in one of the clouds, it's extremely likely you'll already use their internal registry (eg AWS ECR). I know that we do. So it's just a case of setting up a few docker build projects in git that push to your own internal registry.
Is it clear whether the Debian image sources will continue to be maintained?
I do not see direct statements that they will stop maintaining sources in open source.
We'll see :)
It is at the top of the announcement. This only affects OCI images, not source code "The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license."
Bitnami has changed. It used to just be an easy way for me to get a fully configured wordpress installable exe.
Yes, that was worth it. But, other images apart from WP are ...
Anyone using their PHP images? Have you switched to FPM or started to build the bitnami images from source?
> Anyone using their PHP images?
With FrankenPHP, I can't imagine why I'd choose Bitnami anymore.
What are you talking about? Their images have _fewer_ CVEs.
Aren't these Debian images equally "their", but available for free? Aren't the free images what Bitnami is discontinuing?
What timing…
Hack Tagalog
[dead]
[dead]