Why an authentik 2025.10 upgrade starts with PostgreSQL
authentik 2025.10 drops Redis entirely, moving caching, tasks, sessions and WebSocket functions to PostgreSQL. If your deployment still has Redis configured, the upgrade changes where authentik keeps its runtime state, so the database becomes a dependency that must be sized, secured and checked before the new version starts. Treat the PostgreSQL work as the first part of the upgrade plan, not an afterthought once the containers are updated.
Your starting point is a running deployment that still contains Redis settings, most often in the environment or configuration file used by the server and worker containers. Confirm which of your nodes, including any outposts, read those settings, and inventory everything that depends on Redis being present. authentik must also move forward one release at a time under the sequential upgrade rule described in the upgrades group, so 2025.10 is only reachable from the version directly before it. Read the authentik 2025.10 release notes before you pick a target patch level, because they are the authoritative list of required changes for this release.
Plan the PostgreSQL changes with the release notes in hand. The notes warn of roughly 50% more PostgreSQL connections after upgrading, so confirm your current connection limits, pooling approach and headroom with your database owner before the change window. Also confirm whether your PostgreSQL requires TLS, since 2025.10 has specific TLS requirements, and note that the default email scope mapping now returns email_verified as false, which affects any application that reads that claim. Each of these items should have a named owner and a verification step before you schedule the upgrade.
What changes in authentik 2025.10 and what you must do
This table lists each change in authentik 2025.10 that affects an existing deployment, what it does to your running system, and the action to take before or during the upgrade. Read it as a pre-upgrade checklist, since the PostgreSQL and TLS rows matter most for capacity and connectivity. The main takeaway is that Redis removal is not a simple configuration deletion: the database must be sized and tested before the cutover.
| Change | Impact | Action needed |
|---|---|---|
| Redis removed; its work moves to PostgreSQL | Caching, background tasks, sessions and WebSocket functions now run on PostgreSQL, so the database carries load that Redis previously handled. | Confirm every component that depended on Redis is accounted for, then test sessions, tasks and live updates in a staging copy. |
| About 50% more PostgreSQL connections after upgrading | Connection count rises roughly 50% according to the 2025.10 release notes, which can exhaust connection limits and slow logins. | Size PostgreSQL connection limits and memory before cutover, and consider connection pooling such as PgBouncer. |
| Redis settings can be deleted | Leftover Redis configuration has no function in 2025.10 and adds confusion during troubleshooting. | Review environment variables, Compose files and Helm values, then remove Redis settings and any Redis service you no longer need. |
| TLS to PostgreSQL requires TLS 1.3 or Extended Master Secret | If your PostgreSQL connection uses TLS, connections may fail unless the negotiated protocol meets these requirements. | Verify the TLS version and extensions your PostgreSQL server offers, and test the connection from the authentik containers. |
| Default email scope returns email_verified as false | Applications that read the email_verified claim through the default email scope may stop trusting addresses they previously accepted. | Review which relying applications read email_verified, then test their sign-in and decide whether to change the scope mapping. |
What to prepare before you touch the containers
Most failed authentik upgrades trace back to work done before the new image starts, not during it. The six items below cover data you can restore, configuration you can find, database capacity you can measure, and the consumers of identity claims that will change behavior. Finish them in order, because the connection baseline and the test environment depend on the backup and inventory.
Verified PostgreSQL and media backup
Take a PostgreSQL backup and copy the uploaded files that live outside the database, because authentik stores all configuration and data in PostgreSQL except uploads. Restore the backup into a scratch environment and confirm that users, providers and applications appear before you rely on it. A backup that has never been restored protects you from nothing if the upgrade goes wrong. Ask your team who can run the restore and where the copy is kept.
Inventory of Redis settings
Search every environment file, Helm values file and Compose file for Redis host, port, password and TLS settings, including those set through secrets or CI variables. Authentik 2025.10 no longer uses Redis, so these settings are dead configuration, and leftover values can confuse the next person who reads the deployment. Record where each one is defined so you can remove it in the same change that moves the image tag.
PostgreSQL connection baseline
Record the current number of PostgreSQL connections at normal load and at peak, broken down by the server and worker containers and any other clients. The 2025.10 release notes warn of roughly 50% more connections after the upgrade, so this baseline is the only way to size the change. Compare the result with the connection limit and any pooler limits you run. Ask your database owner to confirm the sizing before the cutover window.
TLS posture for the database connection
Confirm whether your PostgreSQL server requires TLS for client connections and which protocol version and key exchange options it negotiates. Authentik 2025.10 needs TLS 1.3 or the Extended Master Secret extension when PostgreSQL requires TLS, so a server that negotiates older settings can fail to connect after the upgrade. Test the connection from the same network path authentik uses, not from your workstation. Record the result next to the backup and baseline.
Applications that read email_verified
List every relying party that reads the email_verified claim from authentik, including custom code, API consumers and any applications that gate account actions on it. The default email scope mapping now returns this claim as false, so an application that trusts it may start rejecting or blocking users. Confirm with each application owner whether the claim is used for access decisions or only for display. Plan a scope mapping change only where a consumer needs the original value.
Non-production test copy
Build a test environment from a copy of production data, with the same PostgreSQL major version, the same authentik release path and the same reverse proxy and TLS settings. Run the upgrade there first and test a real login through each provider type your organization uses, plus the outposts and any LDAP or RADIUS clients. Keep the copy isolated so that test applications cannot send mail or call production systems. Record every change you make so the production runbook matches what you tested.
How the steps differ on Docker Compose and Kubernetes
The authentik Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. On this platform, the 2025.10 change is mostly a matter of editing the Compose file and the environment file, then watching PostgreSQL capacity after the stack restarts. Because the server and worker containers both read the same settings, the Redis cleanup must be applied consistently to each service.
- Redis service and variables: Remove the Redis container definition and any
AUTHENTIK_REDIS__*environment variables from the server and worker services, then remove anydepends_onentries that still point to Redis. - Host sizing: Check that the host still meets the guide's minimum of 2 CPU cores and 2 GB of RAM, and confirm headroom for the roughly 50% increase in PostgreSQL connections.
- PostgreSQL connection limits: Review
max_connectionsand any pooler settings on the PostgreSQL side before restarting, since the database now carries work that Redis used to handle. - Restart order: Pull the new image tag, bring up the stack, and confirm the server and worker both start cleanly before reopening user traffic.
- Single-host risk: Compose runs everything on one host, so a failed upgrade rollback depends on a verified backup of the PostgreSQL data taken before the change.
Before you start, confirm the exact Compose file keys against the 2025.10 release notes for your image tag.
The authentik Kubernetes guide installs with Helm and states that the PostgreSQL bundled with the chart is for demonstration and test environments, recommending a separately managed PostgreSQL for production. For a production cluster, the upgrade therefore starts with confirming that the database is external and sized for the new connection load. The Redis removal then shows up in chart values, which must be cleaned so that no stale Redis settings are passed to the pods.
- External PostgreSQL: Confirm that production values point to a separately managed PostgreSQL, not the chart's bundled database, and that the connection credentials and TLS settings match what the database requires.
- Redis values: Remove any Redis keys from the chart values file and from any overrides in your GitOps repository, so that the rendered manifests no longer reference Redis.
- Connection capacity: Size the managed PostgreSQL for about 50% more connections, and check connection limits on any pooler in front of it.
- Chart version: Confirm the chart value keys against the 2025.10 release notes for the chart version you deploy, because key names can differ between chart releases.
- Rollout and rollback: Use a staged rollout with a tested database backup, since rolling back a migrated schema is not a simple Helm rollback.
Before you upgrade, render the chart with your new values and search the output for any remaining Redis references.
The upgrade sequence, with checks and rollback points
This sequence moves an authentik deployment to 2025.10 in a controlled order, so each change is verified before the next one starts and every stage has a known way back. It produces a production upgrade with a documented test run, a tested backup, and checked login, provider and outpost behavior.
Confirm the current version and upgrade path
Record the running authentik version and the image tags for the server, worker and any outposts, then confirm that the version in place is one the sequential upgrade rule allows you to step from to 2025.10. If the deployment is several releases behind, stop here and follow the catch-up path instead of jumping straight to 2025.10. Done means you have a written version inventory for every container and a documented decision that the path is valid. Read the release notes for 2025.10 in full before continuing, since they list the Redis, connection and claim changes covered in the steps below.
Back up PostgreSQL and uploaded files
Take a logical backup of the authentik PostgreSQL database and a copy of the uploaded files volume, both taken while the stack is quiet or from a consistent point in time. Store them off the host and confirm they can be read back. Verification means a restore of the database into a scratch instance completes and the row counts for core tables look right. This backup is your rollback point for the whole upgrade. If the schema migration fails or behavior is wrong after the upgrade, you restore this backup to a matching authentik version rather than attempting to downgrade the database schema.
Remove Redis settings from configuration
Delete the Redis host, port, password and related keys from your configuration file or environment variables, and remove the Redis service from your Compose file or Helm values. authentik 2025.10 moves caching, tasks, sessions and WebSocket functions to PostgreSQL, so Redis settings no longer apply. Check the configuration in each environment, including test and production, and confirm that no other service in your stack depends on the Redis instance being removed. Done means the configuration diff contains only the Redis removals and no unrelated changes, and the rendered configuration shows no Redis references.
Confirm PostgreSQL connection capacity and TLS
Review the PostgreSQL maximum connection setting and the connection usage of the current deployment, then raise capacity so it covers roughly 50 percent more connections than before, as the 2025.10 release notes warn. Coordinate with your database owner on the limit, any pooler in front of PostgreSQL, and the per-role connection limits. If PostgreSQL requires TLS, confirm that the connection will negotiate TLS 1.3 or use the Extended Master Secret extension, because authentik 2025.10 needs one of these. Verification is a test connection from the authentik containers that succeeds under TLS and a connection count measured under normal load that stays below the new limit.
Upgrade in a test environment
Apply the 2025.10 image tags to the server and worker containers in a test environment that mirrors production in database version, configuration and reverse proxy setup. Watch the startup logs through the database migration and confirm both containers reach a healthy state. Confirm that the web interface loads and that the admin sign-in works. Done means the migration completes without errors, the worker processes background tasks, and the test instance records a clean start. Keep the test environment and its restored data until the remaining checks pass, so you can repeat the upgrade if any check fails.
Run login, provider and outpost checks
Test each login path that matters to your organization against the upgraded test instance: password sign-in, multi-factor prompts, enrollment or recovery flows, and sign-in to a representative application for every provider type you use, such as OAuth2/OIDC, SAML, LDAP, proxy or RADIUS. Confirm that each outpost is connected and reports the expected version. Also check that session behavior is unchanged now that sessions are held in PostgreSQL, including logout and session expiry. Done means each test case has a recorded pass or a logged defect. If a defect blocks a path, the rollback point is still the pre-upgrade backup restored to the prior version on the test instance.
Verify the email_verified claim with each relying application
Because the default email scope mapping now returns email_verified as false, sign in to each relying application in the test environment and check how it reads the claim. Applications that require a verified email before granting access, or that match accounts on this claim, may change behavior. Decide with each application owner whether to keep the default, adjust the scope mapping, or adjust the application. Done means every relying application has a documented result for this claim and a sign-off from its owner. Do not promote to production until this record exists, because the change affects what applications receive, not only what authentik displays.
Upgrade production and confirm the rollback point
Schedule a change window with the application owners, repeat the backup from the earlier step immediately before the change, and then apply the same image tags and configuration changes used in the test environment. Run the same login, provider, outpost and claim checks against production, and watch the logs and connection counts for the first period of normal use. Done means production passes the checks, PostgreSQL connection usage is within the raised limit, and the backup taken before the change is recorded as the documented rollback point. If production fails and cannot be corrected, restore that backup to the prior authentik version rather than downgrading the schema in place.
How to size PostgreSQL for the work Redis used to do
Removing Redis moves work onto PostgreSQL, so the sizing question becomes a connection question. authentik 2025.10 no longer uses Redis at all. Caching, background tasks, sessions and WebSocket functions now run through PostgreSQL, and the release notes warn of roughly 50% more PostgreSQL connections after the upgrade. Before you change anything, record your current baseline: the number of active connections at peak login hours, the number of connections authentik holds per container, and the max_connections value on the server. Use your PostgreSQL monitoring or the pg_stat_activity view to capture these figures over at least one full business cycle, including any batch jobs or directory syncs. Then compare the peak against the configured limit and against any reserved connections for administrators and other applications sharing the server. The gap between peak use and the limit is your headroom. Apply the roughly 50% increase to the measured peak in a test environment rather than assuming the production numbers will hold.
A connection pooler such as PgBouncer is worth evaluating before you raise `max_connections`. Raising the server limit increases memory use per connection and can slow the server under load, so it is often the wrong first step. PgBouncer sits between authentik and PostgreSQL and lets many client connections share a smaller set of server connections. Evaluate it on three points: whether the pooling mode you choose is compatible with how authentik and its database driver use transactions and session state, how the pooler is monitored and restarted, and whether it adds a single point of failure in your setup. Confirm these details with the authentik release notes and your own tests rather than relying on a general rule, and load test the exact configuration you plan to run.
TLS requirements must be checked on both the client and the server before the upgrade. If your PostgreSQL instance requires TLS, authentik 2025.10 needs either TLS 1.3 or the Extended Master Secret extension on the connection. Confirm the TLS version and extensions your PostgreSQL server offers, the settings on any pooler in between, and the TLS configuration authentik uses in its PostgreSQL connection settings. Test the connection from the actual authentik server and worker containers, since a successful connection from a database client does not prove the application will negotiate the same parameters. Record the values you confirm, because sizing and connection settings should come from your own measurements and your own postgresql.conf and pg_hba.conf files, not from example figures in this guide.
What makes this upgrade take longer
This table lists the factors that stretch or shorten the authentik 2025.10 Redis removal work, from Redis settings and PostgreSQL headroom to backups and outpost versions. Read each row against your own environments to see which items will need the most attention before you schedule the change. The main takeaway is that most of the effort sits in inventory and preparation, so a complete list of Redis references, connection limits and relying applications before the change window is the best way to keep the upgrade predictable.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Redis-dependent settings across environments | Redis configuration keys can exist in each environment's variables, compose files or Helm values. authentik 2025.10 no longer uses Redis, so leftover settings need to be found and removed in every copy. | Search every environment's configuration sources for Redis keys before the change. Remove them in version control so production and test copies match. |
| PostgreSQL connection headroom and pooling | The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. Servers sized for the old setup may hit connection limits under load. | Confirm current connection limits and peak usage, raise limits or size a pooler such as PgBouncer where needed, and test under realistic load first. |
| PostgreSQL TLS configuration | If PostgreSQL requires TLS, authentik 2025.10 needs TLS 1.3 or the Extended Master Secret extension. A mismatch can stop the server from connecting after the upgrade. | Check the TLS version and extensions your PostgreSQL endpoint negotiates, and test the connection from the new version in a non-production copy. |
| Relying applications that read email_verified | The default email scope mapping now returns email_verified as false. Applications that gate access on this claim may suddenly deny or change behavior for users. | List each OIDC client that reads email_verified, check its behavior with the new default, and agree on a scope mapping change with each application owner. |
| Custom code or scripts that assume Redis exists | Health checks, backup jobs, monitoring or internal tools may connect to Redis directly or expect a Redis container. These fail silently or noisily after removal. | Inventory scripts, dashboards and sidecar containers that reference Redis, and update or retire them before the cutover. |
| Database size and time for a verified backup | A restore point is the rollback path. Larger databases take longer to back up and to restore into a test copy, which lengthens the change window. | Measure the size of the database and time a full backup and a test restore. Ask for the restore result, not only the backup job's success status. |
| Number of environments and a test copy of production | Each environment needs its own check, and skipping a production-like test copy moves discovery of TLS, connection and claim issues into production. | Upgrade a restored copy of production first, then promote the same configuration to other environments in the same order. |
| Outposts on a matching version | Outposts that run a different version from the core may not work correctly with the upgraded server, which adds a second upgrade to coordinate. | Check the version of each outpost in the admin interface, and plan outpost upgrades alongside the core upgrade. Confirm the exact sequence in the release notes. |
Common questions about the authentik 2025.10 upgrade
What does the authentik 2025.10 upgrade cost in effort, and what drives it up?
The effort depends on how many authentik deployments you run, how much configuration sits in Redis-dependent paths, and how many applications rely on the default email claim. Cost comes from people: your team's time for access, testing and change approvals, plus any partner time under a written scope. The biggest drivers are the number of environments, the PostgreSQL setup (managed or self-run, TLS requirements, connection limits), and the number of integrations that read the email_verified claim. Ask any partner for a quote that lists each environment, each PostgreSQL change, and the testing you expect them to perform. A quote follows from the written scope, so no figure is given here.
How long does the authentik 2025.10 upgrade take?
No fixed duration is given here because the time depends on your environment, not on the release notes alone. The main variables are how many instances you run, whether PostgreSQL needs a connection limit change or a TLS change first, how long your change windows are, and how many application owners must confirm their integrations work. Start by inventorying every environment and every application that uses the default email scope. Then ask a partner for a timeline tied to that inventory and to your approval cycle, with each stage and its dependencies written out.
What must our team provide before an authentik upgrade starts?
Plan to supply the following before any work begins:
- Administrative access to each authentik deployment, its reverse proxy, and its PostgreSQL server
- Staging or test environments that match production closely enough to test login, MFA and application sign-in
- Change windows for staging and production, plus a named rollback decision maker
- Named owners for each connected application who can confirm sign-in and claim behavior after the change
- A current backup of the PostgreSQL database and the authentik configuration
Confirm these with your own change management process before you commit to a schedule.
Can an in-house team complete the authentik 2025.10 upgrade alone?
Often yes, if the team already runs authentik and PostgreSQL and has a staging environment. The work is mostly configuration and testing: removing Redis settings, checking PostgreSQL connection capacity, confirming TLS support, and reviewing the email_verified claim against each application. Teams usually need outside help when the deployment is large, when PostgreSQL is shared with other workloads, when no staging copy exists, or when application owners cannot verify their own integrations. Ask yourself whether your team can run a full test cycle and document the results before production change.
How does removing Redis affect PostgreSQL sizing?
After upgrading, authentik moves caching, tasks, sessions and WebSocket functions into PostgreSQL, and the 2025.10 release notes warn of roughly 50% more PostgreSQL connections. Before the upgrade, check your current maximum connections, your pooling setup, and how much headroom your server has for memory and CPU. Adjust the connection limit or add a pooler such as PgBouncer before go-live, and monitor connection counts during the first days. Remove the Redis settings from your configuration once the new deployment runs cleanly, because they no longer have any function.
What should we do about the email_verified claim change?
The default email scope mapping now returns email_verified as false, so any application that checks that claim may block users or change behavior after the upgrade. Inventory every OIDC or OAuth2 application that reads email or email_verified, then decide whether to keep the old behavior with a custom scope mapping or to update the application. Test a sign-in for each application in staging, and confirm the claim value with the application owner. Document the decision for each application so the change is traceable during review.
Can we roll back an authentik 2025.10 upgrade?
Plan rollback as a restore from backup rather than a simple downgrade. Authentik release and migration behavior means you should take a full PostgreSQL backup and a copy of the configuration before the upgrade, and test restoring it in staging. Record the PostgreSQL connection settings and the Redis settings you remove, so you can reinstate them if required. Confirm the exact rollback procedure for your deployment with the authentik release notes and your own runbook before the change window.
How DeployOpen scopes and delivers the upgrade
DeployOpen plans the authentik 2025.10 upgrade as a written, fixed-scope engagement inside your own infrastructure. We start from your current deployment, its Redis settings, PostgreSQL sizing and client integrations, then build, test and hand over the change with evidence your team can repeat.
How we scope
- Inventory your current authentik version, Compose or Helm deployment, and every Redis setting that the upgrade would make obsolete.
- Confirm PostgreSQL version, hosting model, connection limits and whether the database requires TLS with TLS 1.3 or Extended Master Secret.
- List relying applications that read the email_verified claim, so the written scope covers their expected behavior before any change begins.
How we build
- Prepare a staging copy of authentik and PostgreSQL that mirrors production, then run the upgrade there first.
- Remove Redis configuration in a controlled change, and size PostgreSQL connections for the roughly 50% increase noted in the release.
- Test login, SSO flows, outposts and the email scope mapping in staging, recording each result against the agreed scope.
How we hand over
- Deliver a runbook covering backups taken before the change, the upgrade sequence, rollback steps and post-upgrade checks.
- Document the final configuration, including PostgreSQL connection settings, TLS parameters and any updated scope mappings.
- Walk your operations team through the runbook and the verification evidence so they can repeat the steps for later releases.
How we support
- Support after handover can be arranged as a retainer, with ongoing patching and upgrade work defined in writing.
- Ask for the retainer terms, response expectations and included work in your quote, since these are set per agreement.
- Confirm with your team which authentik release line you will follow, using the project's published security policy as a reference point.
