Bitnami discontinues mostly all free public versioned images with impact for helm-charts

[D3N14L]

Bitnami announced that they will discontinue almost all free versioned container images and only offer latest tags for development / testing purposes.
See bitnami/charts#35164 for details.

This means that pulls for images from helm-chart dependencies in this project WILL BREAK (images can´t be pulled anymore) after 28th of August.

[mgruner]

@monotek do you have any recommendations how we should react to this change?

[monotek]

Wow, that's a bummer :/
Not sure yet how to handle that.
Longterm I guess it would be best to move away from bitnami.

[mgruner]

For the start I believe we could try to freeze the existing subcharts with the bitnamilegacy repository path instead, so that pulling stays functional. But there will be no updates, so that we have to switch to other subcharts at some point.

It would be great to understand if there is some kind of trend in the k8s admin community how to deal with this situation, if there might be a fork / follow up project that takes over these charts as OSS or something like that. Or if there are other charts that we could use instead, and how to create an upgrade path for the user data.

[monotek]

I just read this here after coming back from vacation.
As the discussion is blocked in the Bitnami announcement, I'm not aware of any forks yet or how other people handle it.

[mgruner]

Please see #354 for a temporary workaround. We can't do more than switching to the legacy image repositories for now as a workaround so that pulls keep working after 2025-08-28.

Eventually, the subcharts will have to be replaced due to missing updates, but I don't have any idea about this yet.

[NicoJDE]

for redis and memcached we can switch to dragonfly as drop in replacement? There is also a helm chart available.

[lyz-code]

Hi, bitnami will stop serving the images at the end of the month (if they have not already), so we're afraid that our service will become unavailable. Is there any progress in the migration?

[mgruner]

@lyz-code please see #354. We switched to the legacy images, so that operations should continue. A long term solution is still missing.

[kdambekalns]

The best solution probably is using official charts coming from the used projects:

• Elasticsearch: https://www.elastic.co/docs/deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart
• MinIO: https://docs.min.io/community/minio-object-store/operations/deployments/k8s-deploy-operator-helm-on-kubernetes.html
• Memcached?
• PostgreSQL, maybe switch to CloudNativePG: https://github.com/cloudnative-pg/charts
• Redis?

Oh my, such a single-point-of-failure…

Now I am glad that I did not get around to installing Zammad in our cluster, seems we'll stick to the SaaS for the time being. 😇

[Starfox64]

Correct me if I'm wrong but my understanding of the situation is that Bitnami is retiring the Docker Hub repository but that the GitHub repository, where the Dockerfiles and charts are located, are still maintained (I'm still seeing active commits). So there's nothing to stop us from still using those images, we just have to build them ourselves.

Personally this is what I've done for our project so far, I have a GitHub Action that pulls the bitnami/containers repo and builds it :

name: Build MongoDB Bitnami images

on:
  workflow_dispatch:

jobs:
  mongodb:
    name: Build mongodb
    runs-on: ubuntu-latest

    env:
      IMAGE: mongodb
      TAG: 8.0.13-debian-12-r1

    steps:
    - uses: actions/checkout@v4
      with:
        repository: bitnami/containers
        ref: bfee9167f6bde19777a3567787c71c114f455076

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Login to GCR
      uses: docker/login-action@v2
      with:
        registry: PLACEHOLDER
        username: PLACEHOLDER
        password: PLACEHOLDER

    - name: Build and Push
      uses: docker/build-push-action@v4
      with:
        context: bitnami/mongodb/8.0/debian-12
        push: true
        tags: PLACEHOLDER
        cache-from: type=gha
        cache-to: type=gha,mode=max