Live data from Hacker News

Broadcom to discontinue free Bitnami Helm charts

github.com

81–90 of 142 posts

Re: Broadcom to discontinue free Bitnami Helm charts

#81

The removal (or moving) of the Bitnami images from Docker Hub is going to break a ton of systems that depend on them. I helped set up https://www.stablebuild.com/ some years ago to counter these types of issues, it provides (among other things) a transparent cache to Docker Hub which automatically caches image tags and makes them immutable - underlying tag might be deleted or modified, but you’ll get the exact same o…

That's what the announcement said, there is a copy of everything at https://hub.docker.com/u/bitnamilegacy

Re: Broadcom to discontinue free Bitnami Helm charts

#82
"Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license."

Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?

Re: Broadcom to discontinue free Bitnami Helm charts

#83

The removal (or moving) of the Bitnami images from Docker Hub is going to break a ton of systems that depend on them. I helped set up https://www.stablebuild.com/ some years ago to counter these types of issues, it provides (among other things) a transparent cache to Docker Hub which automatically caches image tags and makes them immutable - underlying tag might be deleted or modified, but you’ll get the exact same o…

That's what the announcement said, there is a copy of everything at https://hub.docker.com/u/bitnamilegacy

Still gonna break everyone’s CI until they manually update the tag. (And who guarantees that these tags will stay alive after they pull this)

Re: Broadcom to discontinue free Bitnami Helm charts

#84
post #60

Bitnami images have been problematic for a little while, especially given their core focus on security but still resulting in a CVE 9.4 in PgPool recently that ended up being used in the underlying infrastructure for a bunch of cloud hosts: [pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8

That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs.

In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.

Re: Broadcom to discontinue free Bitnami Helm charts

#86

Earlier quoted context omitted.

I’ve never used Helm charts. I learned K8S in a shop in which kustomize is the standard and helm is a permitted exception to the standard, but I just never felt any reason to learn helm. Am I missing out? Sometimes the limitations of kustomize annoy me, but we find ways to live with them

Some people like that Helm: - Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/ ) - Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks) - Stores copies/versions/etc of each installation…

> zero to fully running (...) in 5 seconds by just running helm install

Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.

> rollback on failure

This is hardly unique to helm.

> history metadata without (...) some external system

In 2025 you should probably be using gitops anyways, in which case the git repo is your history.

Re: Broadcom to discontinue free Bitnami Helm charts

#87
post #73

Earlier quoted context omitted.

Would you like to count the number of spaces that various items in your manifests are indented and then pass that as an argument to a structure-unaware text file templating engine? Would you like to discover your inevitable yaml file templating errors after submitting those manifests to the cluster? Then yes, you are really missing out!

I really, really, wish we could move away from yaml for tools like this.

If YAML is a foot-gun, templated YAML is a face-cannon.

Re: Broadcom to discontinue free Bitnami Helm charts

#88
post #60

Bitnami images have been problematic for a little while, especially given their core focus on security but still resulting in a CVE 9.4 in PgPool recently that ended up being used in the underlying infrastructure for a bunch of cloud hosts: [pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8

That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs. In the case of…

I mean I understand that's the goal, but in this specific CVE it looks like the issue was introduced in Bitnami's own scripts sitting on top of everything, so a ideally-zero-CVE underlying OS isn't going to solve that problem at all.

It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.

But again, anyone with any knowledge or experience of Broadcom saw this coming, so...

Re: Broadcom to discontinue free Bitnami Helm charts

#89
> Legacy repository migration

> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.

This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.

Basically, I'll need to move to the regular upstream images for:

  * web servers (Apache2 because it's well suited for my needs, but the same would apply to Nginx and Caddy)
  * relational DBs (MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers; as well as PostgreSQL)
  * key value stores (Redis)
  * document stores (MongoDB)
  * message queues (RabbitMQ and NATS)
  * S3 compatible blob stores (MinIO and SeaweedFS)
  * utility containers (like Trivy)
(either that, or I'll need to build them myself if the Dockerfiles remain available)

I'll stay away from Broadcom as much as possible.

Edit:

> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.

Hmmm: https://github.com/bitnami/containers/tree/main/bitnami/mari... and https://github.com/bitnami/containers/commit/7651d48119a1f3f...

Re: Broadcom to discontinue free Bitnami Helm charts

#90
post #63
post #37

Earlier quoted context omitted.

What was the actual risk of using SpringBoot tho?

License changes - BSL or closing the source If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL) Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and indiv…

I think it would be more of a Redis situation - steward changes the license, someone large enough to maintain a fork creates one, and everyone moves to the fork. In Redis's case, Amazon forked it into Valkey.

Spring is so widely used that there are multiple "large enough" companies who could do this

Post reply on HN