Bitnami Helm chart dependencies being deleted in August 2025

[JustinLex]

Broadcom has announced that they are deleting the Bitnami docker images that this helm chart depends on. Existing installs of Postgres, mysql, and redis subcharts will break in August. Future installs using the :latest tag will be extremely fragile.

https://github.com/bitnami/charts/issues/35164

This chart will need to find replacements for these subcharts.

Perhaps integrating CloudNative Postgres will be a good replacement for the database., I already use it in production as an external database.

I am not aware of any production-ready Redis/Valkey templates or operators out there, so it is likely that a new Redis/Valkey template will have to be written for future Redis/Valkey support.

[DreamingRaven]

Hey yes, this is an issue, it is going to be a mess across the board for lots of helm charts that depend on the bitnami charts and their containers.

Redis / valkey should be easy enough. I even have my own helm chart for valkey. https://gitlab.com/GeorgeRaven/raven-helm-charts/-/tree/main/charts/valkey?ref_type=heads although HA is slightly a pain, but because its a kv-store it should not be too bad in any case.

PostgreSQL and potential MariaDB dependencies of the existing chart however a slightly more interesting since it may well involve migrating persistent data. I agree I adore CNPG however if we did go down this path we would need the CNPG CRDs and operator to already be running in the cluster. I would prefer to have a batteries included internal postgresql for testing etc, then allow people to switch it out to use their own external postgresql like that provided by CNPG.

That is my two cents, anyway.

[varet80]

@DreamingRaven I believe the toughest part is the offering of Bitnami to create the users and db for both MariaDB and Postgres. We could use a similar script with the postgres and sql charts.

Thealternative would be to offer instructions how to setup CNPG and parameters examples

I personally use Zalando but thinking to move to cnpg.

[DreamingRaven]

@DreamingRaven I believe the toughest part is the offering of Bitnami to create the users and db for both MariaDB and Postgres. We could use a similar script with the postgres and sql charts.

Thealternative would be to offer instructions how to setup CNPG and parameters examples

I personally use Zalando but thinking to move to cnpg.

Yeah, we could always add our own database provisioning like a post-upgrade hook that gets given the root credentials and just uses them to create whatever user / db is requested.

[LMonert]

Could this be an option for replacing the redis chart? https://github.com/trueforge-org/truecharts

[varet80]

TrueCharts, to my previous experience, proven to be also not so good! and too aggressive towards the way they manage resources. I would think twice before using these

As this experience is from 1.5 years ago. Maybe something changed!

[RubenNL]

2 days to go.

I'd like to see a release which switches to the bitnamilegacy repo. This should be as easy as updating values.yaml:

global:
  security:
    allowInsecureImages: true #required for bitnamilegacy repos
postgresql:
  image:
    repository: bitnamilegacy/postgresql
mariadb:
  image:
    repository: bitnamilegacy/mariadb
redis:
  image:
    repository: bitnamilegacy/redis

I've tested only the redis change, because I already migrated my DB to CNPG.

I'll create a PR for this later today, just so nobody will have issues launching nextcloud after a pod restart/redeploy.

[varet80]

I believe it is time to move Sql and Postgres outside the project? As there is no easy alternative to it. if somebody is planning to use MariaDB or Postgres and cannot maintain them, even sqlite should be enough for that use case. I can be wrong! but generally any thoughts on the subject?

[RubenNL]

Like mentioned above, something like CNPG for postgresql is interesting, but isn't as plug-and-play as just helm install with this chart. Only a couple more minutes of work, but it's still a small barrier to entry.

Something else we need to consider is the migration path to something like CNPG. A upgrade must fail with incompatible options.

[Syntax3rror404]

Better use the official way https://github.com/mariadb-operator/mariadb-operator which is like CNPG but with mariadb instead of postgresql

[varet80]

After long thinking,

offering ability to consume mariadb operator and CNPG operator would be a good way to go.

This means:

• User has to install the operator
• We just apply the CRD and configure NC to use that CRD!

thoughts?

[Syntax3rror404]

@varet80 sounds like a clean solution. 100% consent! Would be nice if users can choose between mariadb or pgsql crs.

The use of operators would also improve backup and restore, update etc.

[varet80]

@wrenix Before I begin implementing this change, your thoughts?

[remram44]

It would be good to still have the option of a bundled database. It's a lot easier for one-off testing or demos.

I will also lament that requiring external things be set up in the global cluster environment kind of goes against the entire point of containerization...

[Syntax3rror404]

It would be good to still have the option of a bundled database. It's a lot easier for one-off testing or demos.

I will also lament that requiring external things be set up in the global cluster environment kind of goes against the entire point of containerization...

You have still the option to use the chart as dependency with a db coming from a top level chart.

And no, like @varet80 said, the chart would add crs for mariadb or pgsql in the feature to create a dedicated db for nextcloud like before.

[varet80]

@remram44 There are thre options

• SQLite (internal small db, for small setups stored in PVC)
• Use a preinstalled, by user, operator for SQL or PG. Following the CNCF Any other helm chart managing Databases will require complex scripting to add users, dbs etc. What Bitnami did.

For the user will still be almost transparent, as the operator is the only piece requiring installation. It has nothing to do with containerization. Operators are containers and these install containers on your k8s clusters. CRD (Custom Resource definitions) are to be used.

If you for instance run prometheus, 99% you have CRDs. ArgoCD, Velero and many more tools move towards this. In other words, do you want a small group of People like me to maintain your Database installation, or a Huge group of people who focus only on how a DB can run in your cluster?

[remram44]

The official Docker postgres image has all those scripts.

[antoinetran]

So I tried to deploy nextcloud helm 7.0.3, and it is now failing because the bitnami redis image does not exist anymore. Let me some time, I might push a workaround PullRequest (if people are interested), so that nextcloud helm latest can still deploy using bitnamilegacy repository, with mariadb + redis.

[RubenNL]

So I tried to deploy nextcloud helm 7.0.3, and it is now failing because the bitnami redis image does not exist anymore. Let me some time, I might push a workaround PullRequest (if people are interested), so that nextcloud helm latest can still deploy using bitnamilegacy repository, with mariadb + redis.

There's already a PR ready. Just needs to be merged.

[RubenNL]

The official Docker postgres image has all those scripts.

CNPG allows for so much more!

Multiple read replicas, automated backups(and restores), easier DB upgrades, and probably some more important stuff I haven't yet used.

Those are all technically possible with a Deployment of postgres in this chart, but do we really want that? The huge complexity?

If we could offload most of that to CNPG, I think this nextcloud chart would improve quite a bit.

[RubenNL]

Bitnami has removed the original images, so we'll get issues about this anytime now.
PR to use the legacy repo still hasn't merged: https://github.com/nextcloud/helm/pull/763

[antoinetran]

Bitnami has removed the original images, so we'll get issues about this anytime now. PR to use the legacy repo still hasn't merged.

I confirm I already had the issue. Bitnami said they would regularly turn off some image to make problem appears on purpose, so that we replace the repository.

I tried the patch and it works.

[albundy83]

Hello,

argo-cd move to https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha for the Redis high availability and for a custom deployment for standalone redis: https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd/templates/redis It could be a way to migrate old bitnami images

[aelek73]

I can recommend to charts of CloudPirates. They are not very old, but I would say they are of good quality, and they use official images. https://artifacthub.io/packages/search?org=cloudpirates

[ThumbGen]

Any other experiences with the Cloud Pirates charts? Why the downvote? Not suitable for Nextcloud, or bad in general? TIA

[aelek73]

I use it in many places and haven't encountered any problems so far (but that's just my opinion). I understand that we're talking about fresh charts, but it's improving day by day and uses official images, which is an advantage in this case.

In my opinion, CNPG and any kind of MariaDB operator would not be a bad choice either, but it would greatly increase the complexity of the whole thing, possibly causing headaches for the existing users. Not to mention the migration from Bitnami's DB installation to the operator one. It's like shooting birds with a cannon. And if a standalone database solution isn't enough for someone, they'll have the time, energy, and knowledge to use an external database.

[JustinLex]

My idea for the CNPG migration, at least for postgres users, would be to make .Values.internalDatabase a legacy option that starts the existing database using the bitnamilegacy image. Then require users to add a new postgresDatabase key that defines the CNPG options for an opinionated CNPG Cluster and optional CNPG ObjectStore and ScheduledBackup. If internalDatabase is defined, then we interpret this as an import situation, and the Cluster will be created with an externalCluster import: https://cloudnative-pg.io/documentation/1.27/database_import/

From the user's perspective, they will update to the breaking-change version, add the postgresDatabase Values, then the chart will do the rest and Nextcloud will begin running on the CNPG database right away on the first try. Once the import is complete, they can delete the old bitnami database by deleting the internalDatabase section.

Moving away from bitnami is a breaking change no matter what we do, but I think importing existing postgres databases into CNPG requires very little effort from users, and will prevent these sorts of breaking changes from unstable leaky abstractions in the future.

[KarlJorgensen]

For redis: This might be an option: https://ot-container-kit.github.io/redis-operator/guide/

TLDR: an operator, where you declare redis instances with a CRD - similar in vein to mariadb-operator and CNPG

[SanoKriss]

Hello,

argo-cd move to https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha for the Redis high availability and for a custom deployment for standalone redis: https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd/templates/redis It could be a way to migrate old bitnami images

what about this https://hub.docker.com/r/valkey/valkey/

[wrenix]

Hello, argo-cd move to https://github.com/DandyDeveloper/charts/tree/master/charts/redis-ha for the Redis high availability and for a custom deployment for standalone redis: https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd/templates/redis It could be a way to migrate old bitnami images

what about this https://hub.docker.com/r/valkey/valkey/

And there Helm-Chart: https://github.com/valkey-io/valkey-helm

I believe that is a good option. (i believe for easy deployment we should not dependence per default on other operators, but still keep an option to use external instances of database.)

@aelek73 has make a suggestion for other helm-charts, too. But i believe this is a small company, should we evaulate other charts? (i do not believe mariadb or postgresql offeres itself in near feature own helm-charts and could use to to startup with old bitnami data/pvcs).

[Syntax3rror404]

I made for example this for my helm charts to use the mariadb-operator with existing or new mariadb instances. It creates or use a existing mariadb and also a user, db, grant etc.

This with a option also to use cnpg with enabled: true/false would be the best solution in the kubernetes universe and the users could choose between mariadb or pgsql with officially maintained and battle tested charts.

Backup restore and also snapshots are automatically possible by the nature of operators.

Working example of my values file

# Use mariadbOperator for creating database, user, grant etc in defined namespace
# This requires a preinstalled mariadb-operator
# https://github.com/mariadb-operator/mariadb-operator
mariadbOperator:
  # enable creating crs for this app
  enabled: false
  # Database created by this chart
  database: nextcloud
  # Username created by this chart
  username: nextcloud
  # Password created by this chart
  password: mynicepassword
  # storageClass for mariadb (not relevant if mariadbOperator.useExisting is used)
  storageClass: rook
  # use a existing mariadb managed by operator and will not create a new mariadb instance for example if you have a one big mariadb or galera
  useExisting:
    # enable use of existing mariadb instance
    enabled: false
    # namespace with existing mariadb managed by operator
    namespace: {}
    # mariadb ref (name in mariadb cr) from existing mariadb
    mariaDbRef: {}

Working example template to the values

{{- if .Values.mariadbOperator.enabled }}
{{- if not .Values.mariadbOperator.useExisting.enabled }}
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb-{{ .Release.Name }}
  namespace: {{ .Release.Namespace }}
spec:
  rootPasswordSecretKeyRef:
    name: mariadb
    key: root-password
    generate: true

  storage:
    size: 10Gi
    storageClassName: {{ .Values.mariadbOperator.storageClass }}

  podSecurityContext:
    runAsNonRoot: true
    runAsUser: 999
    runAsGroup: 999
    seccompProfile:
      type: RuntimeDefault

  securityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop: ["ALL"]
{{- end }}
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: Database
metadata:
  name: {{ .Values.mariadbOperator.database }}
  namespace: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.namespace }}{{ else }}{{ .Release.Namespace }}{{ end }}
spec:
  mariaDbRef:
    name: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.mariaDbRef }}{{ else }}mariadb-{{ .Release.Name }}{{ end }}
  characterSet: utf8
  collate: utf8_general_ci
  cleanupPolicy: Delete
  requeueInterval: 10h
  retryInterval: 30s
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: User
metadata:
  name: {{ .Values.mariadbOperator.username }}
  namespace: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.namespace }}{{ else }}{{ .Release.Namespace }}{{ end }}
spec:
  mariaDbRef:
    name: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.mariaDbRef }}{{ else }}mariadb-{{ .Release.Name }}{{ end }}
  passwordSecretKeyRef:
    name: user-{{ .Values.mariadbOperator.username }}
    key: password
  maxUserConnections: 20
  host: "%"
  cleanupPolicy: Delete
  requeueInterval: 10h
  retryInterval: 30s
---
apiVersion: v1
kind: Secret
metadata:
  name: user-{{ .Values.mariadbOperator.username }}
  namespace: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.namespace }}{{ else }}{{ .Release.Namespace }}{{ end }}
type: Opaque
stringData:
  password: "{{ .Values.mariadbOperator.password }}"
---
apiVersion: k8s.mariadb.com/v1alpha1
kind: Grant
metadata:
  name: grant-{{ .Values.mariadbOperator.username }}
  namespace: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.namespace }}{{ else }}{{ .Release.Namespace }}{{ end }}
spec:
  mariaDbRef:
    name: {{ if .Values.mariadbOperator.useExisting.enabled }}{{ .Values.mariadbOperator.useExisting.mariaDbRef }}{{ else }}mariadb-{{ .Release.Name }}{{ end }}
  privileges:
    - "ALL PRIVILEGES"
  database: "{{ .Values.mariadbOperator.database }}"
  table: "*"
  username: {{ .Values.mariadbOperator.username }}
  grantOption: true
  host: "%"
  cleanupPolicy: Delete
  requeueInterval: 10h
  retryInterval: 30s
{{- end }}