Bug description

Bitnami charts and images are being hidden behind a paywall starting Aug 28 https://github.com/bitnami/containers/issues/83267

Superset deploys with both Postgres and redis from bitnami

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

  • [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
  • [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
  • [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Comment From: rusackas

Well, THAT sucks. CC @mistercrunch to see if any ideas here spring to mind. Time for a new vendor?

Comment From: daveoy

Does the wider Apache community have a strategy for this given that it affects airflow etc too?

Comment From: mistercrunch

Seems this affects helm/ and k8s doc mostly? Find a new source if any (?) Use something ASF-provided? If it's just a few base images we could pull/push them to docker hub on apache/ maybe?

Comment From: OOub

Seems this affects helm/ and k8s doc mostly? Find a new source if any (?) Use something ASF-provided? If it's just a few base images we could pull/push them to docker hub on apache/ maybe?

I'm personally deploying postgres using the cloudnative-pg operator on k8s.

Couldn't find a decent alternative for the redis helm chart so far so I changed the chart values to the bitnamilegacy repository as a temporary solution while working that out.

Comment From: OliverKleinBST

For redis a potential solution could be what they have done in oauth2-proxy helm chart: https://github.com/oauth2-proxy/manifests/releases/tag/oauth2-proxy-8.0.0

Version 8.0.0 of the helm chart removes the dependency on the Bitnami Redis subchart and replaces it with the dandydeveloper/redis-ha chart. Therefore this version introduces a breaking change to the redis subchart deployment configuration.

Read more about it [here.](https://github.com/oauth2-proxy/manifests/tree/main/helm/oauth2-proxy#to-800---bitnami-)

Comment From: mistercrunch

Nothing personal, but dandydeveloper doesn't inspire top confidence.

Can we just push the image to the asf-hosted docker hub? I don't think I have access but our GHA does, we could run a one off to push it.

Comment From: daveoy

is it worth doing that to vendor the charts too? they will also be paywalled

Comment From: duarte-pompeu-feedzai

According to https://github.com/bitnami/charts/issues/35164, it seems the deadline has been extended to September 29th.

Is there a plan to mitigate this?

Comment From: mistercrunch

Personally don't have access to push to ASF-hosted dockerhub but our GHA account does. Maybe someone makes an image uploader GHA that's parameterized (source/target) with a workflow_dispatch trigger and I can trigger it with the right params. That only solves hosting the images for now, we'll have to figure out how to keep updating these images as new versions show up.

Comment From: Nick-ATOR

I just had to manually override my postgresql image to repository: bitnamilegacy/postgresql in values.yaml. I'm shook

Comment From: magnetic5355

Chart is now failing - ImagePullBackOff on redis

Comment From: erikdubbelboer

I just had to manually override my postgresql image to repository: bitnamilegacy/postgresql in values.yaml. I'm shook

@Nick-ATOR How did you do this? I only see bitnami in a comment, I don't see how it's configured in values.yaml?

Comment From: Nick-ATOR

superset-values.yaml

postgresql:
...
  image:
    repository: bitnamilegacy/postgresql
    tag: "14.17.0-debian-12-r3"
...

I haven't tested it on redis yet, but adding the image-repository should work the same way.

redis:
...
  image:
    repository: bitnamilegacy/redis
...

Comment From: duarte-pompeu-feedzai

I also switched to bitnamilegacy for now, as a workaround, but it's not a long term solution.

I think these 2 alternatives have potential: - Docker Official Image - bitnamisecure/redis

Haven't tried them yet, so not sure about effort or impact.

Comment From: mistercrunch

Haven't looked into it, but is copying/repointing to the Apache DockerHub an ok-solution? Like pull/push to hub.docker.com/apache/ and point the helm chart to it? Wouldn't be actively patched/maintained, but at least would provide a place to point to and download from (?)

Comment From: daveoy

This would be the preferred solution for now +1

On Mon, Sep 29, 2025 at 7:29 PM Maxime Beauchemin @.***> wrote:

mistercrunch left a comment (apache/superset#34414) Haven't looked into it, but is copying/repointing to the Apache DockerHub an ok-solution? Like pull/push to hub. docker. com/apache/ and point the helm chart to it? Wouldn't be actively patched/maintained,

mistercrunch left a comment (apache/superset#34414) https://urldefense.com/v3/__https://github.com/apache/superset/issues/34414*issuecomment-3349380882__;Iw!!I6uDfDBXfA!yvpMZJN87U6t0HOerR5wEknwVOf5WJ0AqzqPfidPUYG60lW_V7xuYS79GUQeX7E4WwgnQJ0c4nBKW5ShCGllfHbe5w$

Haven't looked into it, but is copying/repointing to the Apache DockerHub an ok-solution? Like pull/push to hub.docker.com/apache/ and point the helm chart to it? Wouldn't be actively patched/maintained, but at least would provide a place to point to and download from (?)

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/apache/superset/issues/34414*issuecomment-3349380882__;Iw!!I6uDfDBXfA!yvpMZJN87U6t0HOerR5wEknwVOf5WJ0AqzqPfidPUYG60lW_V7xuYS79GUQeX7E4WwgnQJ0c4nBKW5ShCGllfHbe5w$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AEWNPRN3MJXHRIU3HXG4U7T3VG6ETAVCNFSM6AAAAACCYGRMUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBZGM4DAOBYGI__;!!I6uDfDBXfA!yvpMZJN87U6t0HOerR5wEknwVOf5WJ0AqzqPfidPUYG60lW_V7xuYS79GUQeX7E4WwgnQJ0c4nBKW5ShCGkQmcqCmg$ . You are receiving this because you authored the thread.Message ID: @.***>

Comment From: amrishparmar

Just a small note for anyone trying to switch to an alternative repo/image (e.g. bitnamilegacy) using the values.yaml comments as guidance and was wondering why it didn't pick up the version config, it seems as though the comment is incorrectly placed and the image needs to be specified one-level up, i.e. under redis, not redis.master

https://github.com/apache/superset/blob/a66c230058d44dd87d9c7b23c6ed9d50e1d6031f/helm/superset/values.yaml#L871-L873

Comment From: tetebueno

We got rid of any Redis interactions once and for all using Valkey: * deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: valkey
  namespace: the-namespace
spec:
  selector:
    matchLabels:
      app: valkey
  template:
    metadata:
      labels:
        app: valkey
    spec:
      containers:
      - name: valkey
        image: valkey/valkey:9.0-alpine3.22
        ports:
        - name: server
          containerPort: 6379
        livenessProbe:
          periodSeconds: 300
          tcpSocket:
            port: server
        readinessProbe:
          exec:
            command: ["valkey-cli", "ping", "|", "grep", "PONG"]
          initialDelaySeconds: 30
          periodSeconds: 300
  • service.yaml
apiVersion: v1
kind: Service
metadata:
  name: valkey
  namespace: the-namespace
  labels:
    app: valkey
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379
    protocol: TCP
    name: valkey
  selector:
    app: valkey
  • values.yaml
...
    redis:
      enabled: false
    supersetNode:
      connections:
        redis_host: valkey.the-namespace.svc.cluster.local
...

Comment From: OliverKleinBST

We got rid of any Redis interactions once and for all using Valkey:

  • deployment.yaml

apiVersion: apps/v1 kind: Deployment metadata: name: valkey namespace: the-namespace spec: selector: matchLabels: app: valkey template: metadata: labels: app: valkey spec: containers: - name: valkey image: valkey/valkey:9.0-alpine3.22 ports: - name: server containerPort: 6379 livenessProbe: periodSeconds: 300 tcpSocket: port: server readinessProbe: exec: command: ["valkey-cli", "ping", "|", "grep", "PONG"] initialDelaySeconds: 30 periodSeconds: 300 * service.yaml

apiVersion: v1 kind: Service metadata: name: valkey namespace: the-namespace labels: app: valkey spec: type: ClusterIP ports: - port: 6379 targetPort: 6379 protocol: TCP name: valkey selector: app: valkey * values.yaml

... redis: enabled: false supersetNode: connections: redis_host: valkey.the-namespace.svc.cluster.local ...

very nice. I also thought moving to valkey when that Bitnami issue started - to find myself into the only useful helmchart for valkey came from Bitnami....

Comment From: tetebueno

@OliverKleinBST, this seems somewhat up to date: https://artifacthub.io/packages/helm/valkey/valkey