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...
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.
They likely hold a copyright on the exact expression of their documentation, but the facts and information in that documentation, and necessary configuration such as port numbers, and dependency selection are not subject to copyright.
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.
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.
Could you elaborate on your findings?
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.
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
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.
Also it's safer from supply chain attacks. Malware inserted via compromised docker hub tokens is a growing threat.
> Currently there is no cost to contributors or users for Iron Bank. It is a service currently funded by the US Department of Defense.
You can poke around for their public Dockerfile's to build yourself at https://repo1.dso.mil/explore (for example: https://repo1.dso.mil/dsop/opensource/debian/debian12.x/debi...) but to do much useful you'll need an account.
Another organization in Platform One, Big Bang uses IronBank containers to implement a reference DevSecOps CI/CD architecture; I mention them because they maintain a mirror at https://github.com/DoD-Platform-One/bigbang
My experience has been that the cost of “patching” is often bugs and instability, having gained nothing security-wise.
Not that it ever worked well, we had to scale it to 1 because the quorum would constantly break into unrecoverable states.
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.
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"
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.
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.
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.
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.
Same applies to Oracle.
I get that this business model is fashionable amongst wannabe rent-seekers, but it's still antisocial and should be shunned.
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"
Maybe it's just me?
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.
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.
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.
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.
You seem to be confused about who Broadcom is and how they operate. "Long term health" isn't a thing for them. They buy products that are embedded deeply in the fortune 500, cut 90% of the staff, and increase licensing and support 2-100x. They do not care if you are upset. They do not care if you're going to "find something else". They don't care if you build an entire campaign to decry what they're doing.
They know the F500 cannot easily remove them, and that they will have at minimum 5 years to print cash on their service contracts. Sure, some of those F500s will sue them and try to stop the extortion via legal means, but they know that they'll either win, or at worst still be allowed to jack up prices even if a court rules it's not their original egregious asking price.
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.
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.
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.
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.
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.
That said, it seems to be a side effect of their business model that they don't feel they can offer for free, or otherwise choose not to in order to convince people to move. It seems there's nothing stopping someone from forking and/or continuing the packaging for apps they use based on where Bitnami is today. Cool.
I'd personally like to see a lot of these hardening efforts upstream anyway... separating base images for build vs. runtime and more so with the "official" app images themselves. People do and should have different expectations from a lot of applications when packaged in a container vs. installed on a system.
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.
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.
* 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.
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.
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"
Might not be the 'purest' of code, but that's really just vanity to speak like that (as is referring to them as a 'packaging' company).
I highly doubt assembly engineers think of web developers as just 'packaging' their OS calls.
If anyone has tech questions about how it all works, tools we use, customer scenarios, etc I’d be happy to discuss.
Using Bitnami Secure Images: You pull a versioned PostgreSQL image built on a minimal-attack-surface OS (Photon). When a CVE is disclosed or a new upstream version is released, Bitnami’s automation takes care of everything: a new container image (and Helm chart, if applicable) is built, tested, and published to your registry within hours. All you need to do is update to the latest version; no manual CVE monitoring, triage, or patching required.
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?
1: https://edu.chainguard.dev/chainguard/chainguard-images/chai...
It's a good feature, just hasn't been prioritized so far because customers haven't really had trouble with the current basic approach.
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.
(That said, the overhead of the CSR is really not much, from what I can tell. It's pretty lightweight as EU standards go)
> 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
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.
It's a shame that competition for this position has been ramping up lately.
Sadly, it feels like an inevitability at this point.
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.
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.
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).
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.
But, just butting users with "Just do this good practice" or "Just do this NOW" still is an uphill battle and will usually not cause the best effect with users. We're currently doing this while moving our 2-3 artifactories into one. If we just shut this stuff off because "You should have more control with your builds", there'd be a riot.
And sure, some people will still fail the migration no matter what. But such time frames are still punishing any but the most professional companies.
That's all in all the work I consider a good operations team to do. Make a stink, provide a migration path, be noticeable, and push people off of the old stuff. Just breaking things because "you should have" is burning trust by the mile.
Something, something, sticking your hand in a lawnmower and expecting it not to be cut off.
Broadcom is second only to Oracle.
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.
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.
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.
It's on brand when you consider how badly the styling in Rally needs an update.
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.
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.
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.
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.e https://github.com/bitnami/containers/issues/83267#issuecomm...
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.
[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
https://codeberg.org/stagex/stagex/#comparison
Guix optimized for maximizing package and architecture variety quickly and focused on retrofitting supply chain security tactics as a secondary goal later where possible. For example it allows for untrusted packages with binary blobs in the supply chain in cases like Haskell, Ada, and Qemu. Their supply chain security efforts are on a package by package basis and not mandatory, and still assume that all maintainers are unable to be compromised.
Stagex by contrast is a supply-chain-security-first distro that can trust no single maintainer or computer by design. As such, Haskell and Ada are impossible to add support for right now as no bootstrap path exists for them.
With Qemu we did the hard work of learning how to build all those binary blobs ourselves from source because we really needed it.
Guix has by far the best supply chain security of any workstation distro out there, but I would never ever use it in the supply chain of anything bound for high value production use where no single person should be trusted. Guix is also very difficult to use in container environments as it has no signed/reproducible OCI images so you would have to build all that yourself.
That is what stagex was built for.
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/...
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)
You intentionally break something just a little to force dependents to notice, before turning it off completely
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.
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.
I thought it was an analogy to the electrical problem: flickering lights due to high demand.
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.
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.
“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...
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.
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.
I would argue that if you run Kubernetes, then you frequently already have the resource to maintain your own images.
If you don't need the bitnami helm chart functionality, using more stock container images is easy and preferable.
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.
It's time to build your own from core / foundational images - something I recently learned and now seek to master.
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 ;)
"Just go get the DEV image, Josh."
- 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
FROM ubuntu:noble
... (your custom configuration here, default time zones, shells etc.)
RUN apt-get update \
&& apt-get upgrade -y \
&& apt-get install -y \
curl \
wget \
net-tools \
traceroute \
iputils-ping \
zip \
unzip \
&& apt-get clean \
&& apt-get autoremove -y --purge \
&& rm -rf /var/lib/apt/lists/*
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
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)Broadcom is a rat.
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.
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.
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.
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.
> 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.
But yeah seems unlikely that official Debian images would be full of CVEs unless they are not being regularly updated.
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.
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.
Edit: As I see it's true.
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.
We'll see :)
With FrankenPHP, I can't imagine why I'd choose Bitnami anymore.
> 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)