The Deletion of Docker.io/Bitnami

155 zdkaster 74 8/28/2025, 4:37:12 AM community.broadcom.com ↗

Comments (74)

asmor · 1h ago
> 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/

greatgib · 1h ago
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...

supriyo-biswas · 1h ago
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.

progbits · 24s ago
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.
asmor · 1h ago
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.

nopurpose · 1h ago
"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.

tomalbrc · 43m ago
This has to be a joke, right? Months of effort for a makefile? In which world do people live these days
majkinetor · 37m ago
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.
MathiasPius · 3h ago
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.

martypitt · 52m ago
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.

arcanemachiner · 31m ago
Good lord, I didn't know their tentacles were that deep. VMware sure had a lot of touch points.
MangoToupe · 2h ago
This is much less exciting once you realize how evil broadcom is. Still, I suppose we all win in the short term.
elephantum · 3h ago
So, are they evil because they decided to stop sponsoring free network egress?
MathiasPius · 2h ago
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).

tetha · 1h ago
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.

7bit · 1h ago
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.
buzer · 2h ago
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).
systemswizard · 3h ago
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
runamok · 2h ago
Does said network egress cost $50k per user?
ehnto · 1h ago
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.
niemandhier · 1h ago
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.

rahkiin · 2h ago
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.

orthoxerox · 1h ago
Because "bitnami" has brand value. It makes business sense to reuse the name for the new service you are trying to sell.
Aeolun · 1h ago
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”
gexla · 3h ago
Snooping around, it seems the license costs $50K+ annually. I'm not their target market. ;)
Valodim · 2h ago
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

gexla · 1h ago
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.
gexla · 1h ago
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.

zdkaster · 1h ago
The easiest strategy to be profitable as biz without acquiring new users base, lol :P
raesene9 · 3h ago
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.
nloomans · 1h ago
Website got hugged to death: https://archive.is/plsp9
lrvick · 24m ago
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.

quectophoton · 2h ago
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.

prmoustache · 2h ago
Is "brownout" a common or standard term in the industry? First time I see it.
habitue · 1h ago
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)

dkdcio · 8m ago
have also heard this as doing a “scream test” — turn it off, see who screams about it
numpad0 · 1h ago
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/...

aabhay · 2h ago
First heard about this when docker started rate limiting
01HNNWZ0MV43FF · 2h ago
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

miki123211 · 1h ago
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.

znpy · 2h ago
Yes. Going from green to red is called “browning out”.
jacquesm · 1h ago
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.
mattkrause · 2h ago
Is that the origin?

I thought it was an analogy to the electrical problem: flickering lights due to high demand.

wafflemaker · 30m ago
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).
skibz · 1h ago
Is anybody familiar with the differences between the new Bitnami Secure Images compared to images from, say, Chainguard?
r9l · 1h ago
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.

bjornsing · 2h ago
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?
rollulus · 1h ago
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.
alias_neo · 2m ago
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.

ctippett · 1h ago
If I had to hazard a guess, it's so the downtime is noticed across various different timezones.
imiric · 1h ago
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.

Xeago · 1h ago
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.

zdkaster · 55m ago
Agreed, Bitnami images often feel over-engineered.
notimetorelax · 3h ago
Is anyone working on mirroring the images and keeping them updated?
mrweasel · 2h ago
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.

tux3 · 1h ago
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.

mrweasel · 1h ago
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.

miyuru · 1h ago
> 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.

kappuchino · 3h ago
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.

shellwizard · 3h ago
Would you kindly share how to do it?
KronisLV · 1h ago
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:

  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/*
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.
runamok · 2h ago
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.
finaard · 2h ago
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:

  - Drastically reduced CVE count (e.g., 100+ CVEs to in some cases 0)
asimovDev · 2h ago
Anyone using their PHP images? Have you switched to FPM or started to build the bitnami images from source?
repox · 2h ago
> Anyone using their PHP images?

With FrankenPHP, I can't imagine why I'd choose Bitnami anymore.

pveierland · 3h ago
Will any source to build new images remain available without subscription?
elephantum · 3h ago
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

KronisLV · 2h ago
> 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.

elephantum · 3h ago
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
aeijdenberg · 2h ago
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

raffraffraff · 2h ago
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.
pveierland · 3h ago
Is it clear whether the Debian image sources will continue to be maintained?
elephantum · 3h ago
I do not see direct statements that they will stop maintaining sources in open source.

We'll see :)

davidAlm · 1h ago
What timing…