On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
I quite like Micronaut, especially the ability to use its compile time DI as a standalone library in a non-Micronaut app.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
The source code for Bitnami containers and Helm charts remains publicly available on GitHub and continues to be licensed under Apache 2.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
What about the bitnami:minideb base image?
Or the stacksmith files necessary to build certain images?
Without access to these resources, it will not be possible to rebuild the images, will it?
Projects like Sealed Secrets and minideb remain unaffected by these changes. Container images for both projects will continue to be released on Docker Hub (docker.io/bitnami) as usual, without any modifications.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
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
I suggest checking out Anemos (https://github.com/ohayocorp/anemos), the new boy in the town. It is an open source single-binary tool written in Go and allows you to use JavaScript/TypeScript to define your manifests using templates, object oriented approach, and YAML node manipulation.
Most on this thread are viewing helm from a user perspective: "I want to install X and I can use somebody's chart for it or I can use another tool."
There is another category of users who want a way to mange multiple vendor offerings in a consistent manner into their clusters. If they're all packaged with Helm, the user can have standard process and tooling to do that. It's done for K8s apps what containers did for executables.
Is it great? No, see the grief and pain in sibling threads. Are there alternatives? Sure. But Helm is sort of a standard at this point, warts and all.
I work for a vendor that sells to the second category usually, my chart has some 45 images with some intricate hooks for install and upgrade, subcharts, multiple namespaces, etc. You'd be hard pressed to repackage our stuff for every release we give you.
This announcement is a little hard to read. They make it seem that the current images under docker.io/bitnami/* get deleted on August 28? But individual chart READMEs seem to say that images will move during a period starting on August 28 and ending two weeks later? But looking at https://hub.docker.com/u/bitnamilegacy images have been copied already?
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
Hi, former cofounder of Bitnami here. I left VMware quite a while ago, so not involved with this. The technical team at Bitnami is still top notch and great people. I am quite baffled at this business decision.
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:
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 original image back.
"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?
> 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.
29 comments
[ 2.9 ms ] story [ 67.2 ms ] threadOn that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
I’m surprised anybody works at bcom these days.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
I don't know why but Artifact Hub never shows up in Google search when you search for "web site with helm charts". Hopefully this gives it a boost.
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
You can read a comparison with Helm here: https://www.ohayocorp.com/anemos/docs/comparison/helm
P.S. I am the author of the tool.
There is another category of users who want a way to mange multiple vendor offerings in a consistent manner into their clusters. If they're all packaged with Helm, the user can have standard process and tooling to do that. It's done for K8s apps what containers did for executables.
Is it great? No, see the grief and pain in sibling threads. Are there alternatives? Sure. But Helm is sort of a standard at this point, warts and all.
I work for a vendor that sells to the second category usually, my chart has some 45 images with some intricate hooks for install and upgrade, subcharts, multiple namespaces, etc. You'd be hard pressed to repackage our stuff for every release we give you.
From ticket https://github.com/bitnami/charts/issues/35164:
> Now – August 28th, 2025: Plan your migration: Update CI/CD pipelines, Helm repos, and image references
> August 28th, 2025: Legacy assets are archived in the Bitnami Legacy repository.
From README https://github.com/bitnami/charts/blob/4973fd08dd7e95398ddcc...:
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
[pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8
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?
> 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:
(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...