All Modern Digital Infrastructure Rests on Bitnami Container Images
Description
An XKCD-style black and white comic showing a massive, precarious tower of blocks labeled 'ALL MODERN DIGITAL INFRASTRUCTURE' at the top. The tower is complex and unstable-looking, with various components stacked haphazardly. An arrow points to a small foundational block near the bottom with the label 'Bitnami Charts and Container Images after August 28th.' This is a parody of the famous XKCD 2347 'Dependency' comic, adapted to reference the critical role Bitnami Helm charts and container images play in modern infrastructure, and the anxiety around changes to such foundational dependencies
Comments
39Comment deleted
Somewhere, a single Bitnami maintainer is blissfully unaware that half the Fortune 500's prod environments depend on their weekend hobby project. The 'August 28th' cutoff is just the date they finally read the codebase
Our entire infrastructure's disaster recovery plan is basically hoping that the person who maintains that one critical base image doesn't decide to learn Rust on a Friday afternoon
Remember when we said containers made infra disposable? Turns out the disposal date was August 28th - Bitnami just scheduled our outage for us
The microscope metaphor is perfect - we spent so much time examining our microservices under high magnification that we didn't notice Bitnami was the lens holding the entire optical system together. Now we're all scrambling to migrate before our 'modern' infrastructure becomes a case study in why 'it's just a helm chart' is the new 'it's just a small library update.'
This perfectly captures the moment every senior engineer dreads: when you realize your entire production infrastructure is held together by a single Helm chart from a registry that just announced its deprecation. It's not technical debt - it's technical Jenga, and someone just pulled out a load-bearing block. The real kicker? You have 47 microservices, 12 environments, and exactly one weekend to migrate everything before Monday's deploy. Welcome to cloud-native architecture, where 'highly available' means 'available until a third-party decides it isn't.'
Our cloud‑native platform turned out to be 200 microservices and one Bitnami Helm chart tagged latest - Aug 28 taught us that digest pinning beats hope
Bitnami post-Aug 28th: Turning 'lightweight containers' into a Jenga game where pulling one dep collapses your entire namespace
We did multi‑region, blue/green, and chaos testing; turns out our actual SPOF was values.yaml pointing to bitnami/*:latest - Aug 28 converted our HA design into ‘docker login’ architecture
My DevOps was crying that day Comment deleted
It wasn't just this day Its still ongoing event 🌚 Comment deleted
We're still crying to this day Comment deleted
Bitnamin did not make him cry. He made himself cry. Comment deleted
tldr? Comment deleted
Clusterfuck dependency deprecation, helm charts and docker images affected Comment deleted
Happened because company managing many popular public images and charts, Bitnami, is acquired by Broadcom. Broadcom is moneyhungry and wants everyone to shift toward paid “Bitnami Secure” subscriptions, costing $50,000–$72,000 per year. https://northflank.com/blog/bitnami-deprecates-free-images-migration-steps-and-alternatives Comment deleted
bitnami as in moodle bitnami? fuck. fuuuck. shit. fuck! Comment deleted
wait nvm despite being in a "bitnami" folder, moodle doesn't seem to be related to bitnami at all =w= huh well, I'm glad Comment deleted
(context: I work a lot with moodle's backend. I was fearing the backend would get even worse because of broadcom) Comment deleted
Oh that explains it Comment deleted
fuck broadcom with a shovel... Comment deleted
So just copy the chart and maintain it yourself pussy Comment deleted
No shit, why didn't anybody think of this before, you're such a genius Comment deleted
Have you seen the bitnami stack? Their images are tailored to the charts, so no vanilla upstream available for the image, means also no possibility to just fork the chart Comment deleted
You have fucking ai to do it now Comment deleted
now your nickname makes more sense Comment deleted
We used to package everything our damn selves and it was fine Comment deleted
sucks to suck Comment deleted
I don't understand how we got to the point that unavailability of oss project or its parts results in failure of some local IT system or process. Comment deleted
Would it be better if those IT departments took it in the rear (nonconsensually) from enterprise software providers? Comment deleted
It's not about oss vs. paid services. It's about having local completeness to run, maintain and update some it system. Comment deleted
Many IT departments are understaffed and underfunded. They don't have the time to manually build images and keep up with package updates Comment deleted
Then dont use images. Just put linux server (vm or bare metal) run apt-get install until everything is in place and carry on. Comment deleted
Local caching image repo costs less to run than the traffic for constantly downloading from the interwebs. Comment deleted
cached images aren't updated and would need to be replaced anyway Comment deleted
ORLY? Comment deleted
Thats not what i mean Comment deleted
The dependencies inside the image will become out of date and need updating Comment deleted
This particular problem is not about updating software but reliance on external services. Imagine servers becoming pumpkins the moment they don't have connection to their update servers (hi, Cisco🙂) Comment deleted
just replace repo, bitnami=>bitnamilegacy, meh Comment deleted