How does the authentik team wants to move forward with the Bitnami changes

[Munsio]

For those who didn't know about it: https://github.com/bitnami/containers/issues/75671

With January 6th 2025 Bitnami only releases their latest branch for free (PostgreSQL 17) updates to older versions are going to vanish behind a paywall.

Also all free Bitnami Helm charts and containers will be subject to standard pull-rate limits and pull caps in Docker Hub.

As the Helm chart for authentik is using PostgreSQL 16 that version will never get any security updates anymore unless switched to 17.

I am using Authentik in an homelab environment so my personal impact may not be that big and meaningful but for others it might, so I wanted to ask if you want to move forward with Bitnami charts and latest versions or if you want to switch to a different source.

[rissson]

We've seen this and are discussing it internally with the team. We'll get back here with a response once we have one. Thank you for bringing this to our attention

[Subkrys]

Hi team, any update on this topic ?

[rissson]

We've decided we will now aggressively update to the latest version of dependencies with each authentik release (excluding patches).

For the 2025.4 release:

• the Redis chart will be upgraded to the latest version. As the image is not pinned, it will also get upgraded
• the PostgreSQL chart will be upgraded to the latest version, but the image will remain pinned to 15.8.0-debian-12-r18.

We will most likely release a 2025.5 version (otherwise it will most likely be 2025.6) with:

• the Redis chart will be ugpraded to the latest version again
• the PostgreSQL chart will be upgraded to the latest version again, and the image will no longer be pinned, which will bring it to PostgreSQL major version 17

This will require following PostgreSQL major upgrade steps, for which we provide some documentation at https://docs.goauthentik.io/docs/troubleshooting/postgres/upgrade_kubernetes.

For subsequent releases:

• the Redis chart will be upgraded to the latest version
• the PostgreSQL chart will be upgraded to the latest version, with major upgrades being called out in authentik release notes

[prom3theu5]

Just to chime in - I've been running since January with 17.2 fine

[jyoungs]

FWIW, the Argo project uses https://github.com/DandyDeveloper/charts/blob/master/charts/redis-ha ; which (having used both) I like a lot better.

[rissson]

Agreed, and that's what we use internally. As that would be a breaking change, and as we are slowly removing Redis as a dependency, we probably won't make the switch.

[rissson]

Also, since this issue has been addressed, I'm gonna go ahead and close it.

[rouke-broersma]

@rissson Vmware has today announced the next phase in their scaling down of free Bitnami public catalog: https://github.com/bitnami/containers/issues/83267

TLDR; Bitnami images will only have the latest tag. Images will no longer be versioned depending on the upstream tool version they are using. There likely won't be any changelogs so it will be a lot of work to determine which image hash should be used to target a specific software version.

[CodeAdminDe]

I'd recommend a switch to CNPG (https://cloudnative-pg.io). I switched over months ago and it works like a charm. Official inclusion would be awesome. :)

Anyway. I'd like to say thank you for the fact that authentik is, and stays opensource. It's the best IdP solution out there in my opinion. I hope that more people (and companies) will switch. :)

[rissson]

Thank you for pointing this out to us. We'll look into next steps, but I don't see any good solution yet.

[Starttoaster]

I just pulled off a migration from bitnami/postgres to the cnpg operator that @CodeAdminDe mentioned! Basically followed the process outlined in https://docs.goauthentik.io/docs/troubleshooting/postgres/upgrade_kubernetes to dump and restore the authentik database into a cnpg cluster with the following configuration:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: authentik-postgres
spec:
  bootstrap:
    initdb:
      database: authentik
      secret:
        name: authentik-authy-user
      owner: authy
  imageName: ghcr.io/cloudnative-pg/postgresql:17.5
  instances: 3
  storage:
    size: 10Gi
    storageClass: ceph-rbd
---
apiVersion: v1
stringData:
  username: authy
  password: $CNPG_AUTHENTIK_POSTGRES_PASSWORD
kind: Secret
metadata:
  name: authentik-authy-user
type: kubernetes.io/basic-auth

and the following helm values.yaml:

authentik:
  secret_key: "$AUTHENTIK_SECRET_KEY"
  postgresql:
    host: "authentik-postgres-rw.authentik.svc.cluster.local"
    name: "authentik"
    user: "authy"
    password: "$CNPG_AUTHENTIK_POSTGRES_PASSWORD"
    port: 5432

postgresql:
  enabled: false

redis:
  enabled: true
  master:
    persistence:
      enabled: true

When I imported the database I just port forwarded the authentik-postgres-rw.authentik.svc.cluster.local Service.

Just in case it helps future people looking to migrate away from bitnami resources. Now I just need to migrate off of the redis chart... Speaking of redis, is there any word on when redis may not be needed by Authentik at all?

[x-0D]

There are currently no true alternatives to the Bitnami Helm chart for PostgreSQL, as other well-known Postgres charts are either deprecated or unmaintained, but theres alternatives that should fit project requirements. While CockroachDB offers a cloud-native solution with a Helm chart, its licensing model is not fully open-source, which can pose challenges for adoption in some environments. As an alternative, it may be worth considering YugabyteDB, which provides a fully open-source, PostgreSQL-compatible (based on a fork of postgresql) distributed database, and is available as a Helm chart. YugabyteDB is an actively developed project and could serve as a viable cloud-native alternative to the existing PostgreSQL solution.

https://github.com/yugabyte/yugabyte-db/

https://docs.yugabyte.com/preview/tutorials/quick-start/kubernetes/

As a user concerned about migrating from the Bitnami charts, I have not found any alternatives that will retain the ease of deployment of authentik with the proper level of product support.

[Starttoaster]

There really isn't a Bitnami-alternative to Redis is my main concern, personally, so it sort of sucks that we'll probably just be forced into using Bitnami's :latest redis image. For Postgres I think the cnpg Postgres operator nets you some really nice database management patterns. Switching to Yugabyte feels a bit like chasing the shiny new software name in the catalogue.

[rissson]

So the current plan is to provide our own postgres and redis deployments, but recommend that something else is used for production deployments. Hopefully we can do this with minimal breaking changes. We'll do this for our 2025.8 release.

If anyone knows of good and well maintenained alternatives charts for standalone postgres, we are happy to hear any suggestions. We however don't want to depend on a specific postgres operator.

For redis, we are actively working to remove it as an authentik dependency, so a custom deployment won't be too much of an issue, as it'll only be used for 1-3 releases

[fsmalton]

So the current plan is to provide our own postgres and redis deployments, but recommend that something else is used for production deployments. Hopefully we can do this with minimal breaking changes. We'll do this for our 2025.8 release.

Hello,

I am trying to plan for an upgrade with good time prior to the 28th August Bitnami changes - have you got a target date for Authentik 2025.8?

Thanks, Matt.

[rissson]

Target date is currently the 20th, but that might move further along if we find issues with the release.

[rissson]

In any case, I'd recommend you move to a postgres deployment that you manage

[derritter88]

Beside an official helm chart for Redis wouldn't it "just" work if you reference within your Authentik helm chart to the official Redis Docker Hub image and we get it from there?

[rouke-broersma]

Beside an official helm chart for Redis wouldn't it "just" work if you reference within your Authentik helm chart to the official Redis Docker Hub image and we get in from there?

That is a solution that may work, that needs to be investigated. However I would assume that to be a temporary solution and prepare for the scenario that the Helm charts are pulled as well.

[derritter88]

Beside an official helm chart for Redis wouldn't it "just" work if you reference within your Authentik helm chart to the official Redis Docker Hub image and we get in from there?

That is a solution that may work, that needs to be investigated. However I would assume that to be a temporary solution and prepare for the scenario that the Helm charts are pulled as well.

Another idea: Would it make sense to persist the current sessions within Postgresql? I am not too much into RDBMS vs Key-Value-DBs so I do not know if there would be any big performance impact but it would simplify deployments as you would only need one database.

[CodeAdminDe]

That's possible. Would have slightly less performance for the kv (based on online search, no personal experience yet) ... but I'd love to see these kind of implementation due the fact that Postgres is used anyway. :)

[FelixDobler]

I believe migrating to one database would also increase consistency of manually created backups (using pg_dump and redis SAVE/rdb). Currently, except for using group volume snapshots, the state of the postgres database and redis cache cannot be saved at one singular point in time; changes could be introduced between the individual backup operations.

I'm not sure how much this actually impacts the application's data consistency, but it is something that would be improved as a nice side effect.

[rissson]

Another idea: Would it make sense to persist the current sessions within Postgresql?

This is already the case since 2025.4. With 2025.8, tasks will also be handled by the database alone.

Redis will only be used for caching and websockets. We plan on removing those use cases for 2025.10 or 2025.12.

[derritter88]

Another idea: Would it make sense to persist the current sessions within Postgresql?

This is already the case since 2025.4. With 2025.8, tasks will also be handled by the database alone.

Redis will only be used for caching and websockets. We plan on removing those use cases for 2025.10 or 2025.12.

So for the time being we are "only" talking about having a Redis deployment for a few months (until 2025.12 is being released). If so I think we should be able to deal with Bitnamis "latest" image stuff.

[rissson]

So, change of plans. For 2025.8, we'll update our default values to use the docker.io/library/postgres:17 image, with extra compatibility values so that the upgrade is seamless.

For Redis, we'll probably do the same but with docker.io/library/redis:8.2.

[D1StrX]

Any thoughts on supporting Valkey, as using the Bitnami Redis (cluster) Helm Charts suffer from the same Bitnami changes? Having a HA Redis cluster isn't a nice-to-have feature imho.

[rissson]

Read above, we're planning to remove redis for 2025.10, so we won't be spending time on this. You can deploy valley instead of redis yourself if you want to.

[D1StrX]

Read above, we're planning to remove redis for 2025.10, so we won't be spending time on this. You can deploy valley instead of redis yourself if you want to.

I did deploy Valkey, but I got errors saying SET and GET commands are not known.

[ojsef39]

Read above, we're planning to remove redis for 2025.10, so we won't be spending time on this. You can deploy valley instead of redis yourself if you want to.

Hey there, quick question looking at the recent releases, was redis removed? since it’s still in the chart? looking forward to updating and finally getting rid of redis :)

[rissson]

Starting from 2025.10, you can disable redis in the chart. We'll remove it completely from the chart for 2025.12