Planning an authentik 2026.8 upgrade without losing client IP handling
If authentik sits behind one or more reverse proxies, the most important step before moving to 2026.8 is to list every proxy address in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. From 2026.8, forwarded headers are used only when they arrive from networks in that list, so a proxy that is missing from it will still send requests, but authentik will stop trusting the client address and protocol information those headers carry. Build the list from the addresses your proxies actually connect from, not from the addresses your users appear to use, and confirm it on a staging copy before the production change window. The supported path is sequential: move to the latest patch of each intermediate release in turn rather than jumping straight to 2026.8. Under the authentik security policy, only 2026.5.x and 2026.8.x receive security fixes, and the project announces security releases at least 24 hours in advance, so teams still on older lines should plan the move as a security item, not a feature upgrade.
Upgrades are worth scheduling now because the latest release on the GitHub releases page at the time of research was 2026.8.4, published on October 14, 2026. Plan to pin an exact patch tag rather than a floating minor tag, so the version you test is the version you deploy. Before you start, check which proxy each route passes through, including any load balancer or ingress in front of the reverse proxy, because each hop can change which address authentik sees. Ask your own team to confirm which networks those hops use in your environment, and record that inventory with the change ticket. Keep a rollback plan based on a restored backup, not a downgrade, since the release notes do not describe a supported path back to an earlier version.
Which 2026.8 changes affect your deployment
This table compares the four 2026.8 changes by what they alter in a running deployment and what you must do before or during the upgrade. Read each row against your reverse proxy, WebAuthn policies and any scripts or automation that call the server binary. Any row that matches your environment is a pre-upgrade task, not a post-upgrade fix.
| Change | Impact on your deployment | Action needed |
|---|---|---|
| Forwarded headers accepted only from AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS | Forwarded headers are ignored from networks not listed, so client IPs and logs may show proxy addresses instead of users' addresses | List every reverse proxy address in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS before upgrading and confirm client IPs in logs afterward |
| Removal of the WebAuthn Prevent duplicate devices option | Any policy or configuration that sets this option no longer applies, so duplicate passkey or security key registrations may become possible | Export current WebAuthn settings, record the intended duplicate-device rule, and document any compensating control your policy requires |
| hash_password reads from a prompt or stdin | Scripts that pass the password as a command-line argument or expect the older behavior may fail or hang | Find every automation calling hash_password, then update it to supply the password through a prompt or stdin and test it in staging |
| Rust rewrite of the server entrypoint and proxy outpost | Custom startup wrappers, entrypoint overrides or images that depend on the previous entrypoint behavior may break; proxy outposts change with the core | Review container entrypoint overrides and custom images, and confirm with the vendor release notes that outposts are upgraded to the matching version |
How trusted proxy CIDRs change client IP handling
From authentik 2026.8, forwarded headers are read only when the request arrives from a network listed in `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`. Any hop that is not on that list is treated as the client itself, so the address authentik records may become the proxy or load balancer address instead of the user's address. The effects reach further than the audit log: policies that match on client IP, GeoIP checks, reputation scoring and any rule that limits sign-ins by network can all start evaluating the wrong address. Failures of this kind often look like a sudden spike in blocked logins or a flood of events from one internal address, so the symptom can point you away from the cause.
Start with an inventory of every hop between the client and authentik. Include the edge load balancer, any CDN or WAF, the reverse proxy, the Kubernetes ingress controller and any service mesh sidecar or node-level address that forwards traffic to the authentik server. For each hop, record the address range it sends traffic from, not only the one IP you see in a dashboard. Derive the CIDR values from your own network and cloud routing tables. Do not copy example ranges from documentation, and confirm with your network or platform team which addresses change during failover, scaling or node replacement, because a list that is correct today can drop a hop after a rollout.
Before cutover, run a test in a staging environment that mirrors the production proxy chain. Send a sign-in request through the full path and check the client address recorded in the authentik event log and in any policy that uses the client IP. Repeat the test from a known external address and from a second network path. Confirm the upgrade notes for the exact behavior of the setting in your version, and plan to roll back the proxy list if a hop is missing. Treat the result as a gate: if the recorded address is still a proxy address, do not move production to 2026.8 yet.
What to prepare before touching the server image
Most authentik 2026.8 upgrade problems come from assumptions about proxies, scripts and devices that surface only after the new image is running. The cards below cover what to inventory and test first, so the rollback path is proven before the server container changes.
Full PostgreSQL backup and restore test
Take a full PostgreSQL backup and restore it into a scratch database before the upgrade. Rollback is a restore from backup, not a downgrade, so the restore is the step to prove. Confirm the restored instance starts with the same configuration and that users can sign in against it. Record who can run the restore and how long it took on your hardware, so the rollback window is known before the change starts.
Inventory of reverse proxies and ingress paths
From 2026.8, forwarded headers are used only from networks listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. List every reverse proxy, load balancer and Kubernetes ingress controller that forwards traffic to authentik, including their egress addresses after NAT and any sidecar or service mesh hops. A missing address makes client IPs, scheme and host headers untrusted, which can break login redirects and audit logs.
Scripts and runbooks calling hash_password
The hash_password command now reads the password from a prompt or stdin. Search your automation, configuration management code, break-glass runbooks and shell history templates for calls to this command. Each caller needs to pass the password in the new way and be tested against a non-production instance. Scripts that fail silently can leave an administrator without a working recovery path.
WebAuthn policies and enrolled devices
The Prevent duplicate devices option for WebAuthn was removed in 2026.8. List the WebAuthn stages and policies that reference it, and note which of them users rely on for passkeys or hardware keys. Export a count of enrolled WebAuthn devices per user group so you can check after the upgrade that enrollments and sign-ins still behave as expected, and tell users in advance if their enrollment flow changes.
Staging environment matching production
Run the 2026.8 upgrade first in a staging environment built from the same configuration, PostgreSQL version, reverse proxy setup and integrations as production. Use a recent copy of production data where your policies allow it. The server entrypoint and proxy outpost were rewritten in Rust in this release, so test sign-in flows for each application class, not just the admin login. Keep the staging results with the change record.
Outpost version inventory
List every outpost (proxy, LDAP, RADIUS and RAC) with its image tag and the core version it is paired with, including outposts deployed outside the main stack. Mismatched versions are a common cause of failures after a core upgrade. Plan the outpost image updates for the same change window, and confirm in the admin interface that each outpost reports healthy after the core restarts.
Upgrade sequence with checks and rollback points
This sequence moves authentik from its current supported release to 2026.8 in staging first, with a verified trusted proxy list, a restorable database backup and a checkpoint at each stage. Production follows only after staging logins, MFA and outposts have been confirmed.
Confirm current version and target path
The platform owner records the running authentik version from the admin interface and confirms that 2026.8 is the next target on the supported path, using the authentik security policy and release notes. Versions are not skipped, so a deployment several releases behind needs its own staged catch-up first. The output is a written version record for staging and production. Rollback point: no change has been made, so the team simply stops if the current version is outside the supported path and plans a catch-up.
Inventory reverse proxy addresses for trusted proxies
The platform team lists every reverse proxy, load balancer and ingress address that forwards requests to authentik, including the path through each layer. From 2026.8, forwarded headers are used only from networks in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, so this list must be complete before the upgrade. Confirm the list with the network team against the actual hop addresses seen in staging logs. Rollback point: this step changes nothing in production, so the inventory can be revised freely until it matches what the logs show.
Set trusted proxy CIDRs and verify client IPs in staging
In the staging environment only, set AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS to the inventoried ranges using your Docker Compose environment file or Helm values, then deploy the current version before the upgrade so the setting is tested on the release you already run. Check that the audit events and login records show the real client addresses rather than proxy addresses. Rollback point: if client IPs are wrong, remove the setting change and redeploy the prior configuration, since no schema change has happened yet.
Back up PostgreSQL before upgrading
The database owner takes a logical or physical PostgreSQL backup of the authentik database, since PostgreSQL stores all configuration and data except uploaded files. Store the backup outside the host that runs authentik and test that it can be restored into a separate instance. Record the backup identifier and time in the change record. Rollback point: this backup is the restore path if a migration fails, because authentik does not support downgrades and a restore is the fallback described in the upgrade guidance for this release line.
Upgrade staging server and worker together
Change the image tag for the authentik server and worker containers in staging to 2026.8.x, then roll both to the new version using your Docker Compose or Helm release, so the server and worker run the same release. Watch the server logs for migration completion before opening the admin interface. Note that 2026.8 removes the WebAuthn Prevent duplicate devices option and changes hash_password to read from a prompt or stdin, so check any scripts that call that command. Rollback point: restore the staging database backup and redeploy the prior image tags if migrations fail.
Verify logins, MFA and outposts in staging
Test a representative set of flows: a password login, each second factor in use (including WebAuthn enrollment and sign-in for existing keys), an OAuth2 or SAML application sign-in, and a user session that passes through the proxy. Confirm that LDAP or RADIUS outposts still authenticate and that the proxy outpost reports healthy. Check that client IPs in logs still match expectations. Record every failure against a test case. Rollback point: if any core flow fails, restore the staging backup and keep production on the current version until the cause is fixed.
Repeat the sequence in production
Apply the same trusted proxy setting, take a fresh production PostgreSQL backup, upgrade the server and worker together, and repeat the login, MFA and application checks against production with a small set of test accounts. The change owner signs off only when these checks pass and the audit log shows correct client addresses. The maintenance window and approval path are set by your own change process. Rollback point: restore the production backup taken in this step and redeploy the previous image tags, which the team should have captured before the change.
Update outposts to match the core version
After the core is stable, update each LDAP, RADIUS, proxy and RAC outpost to the same 2026.8.x version as the server, either through the integration that manages them or by changing its image tag, then confirm each outpost reports the new version and healthy status in the admin interface. Because the proxy outpost was rewritten in Rust in this release, retest forward-authenticated applications after the change. Rollback point: an outpost can be returned to its previous tag, but confirm compatibility with the core before running mixed versions for long.
WebAuthn duplicate devices and hash_password: what to change
authentik 2026.8 removed the WebAuthn Prevent duplicate devices option. If your current configuration relies on it, that behavior will not be available after the upgrade, so you need to decide how your organization handles users who register the same authenticator more than once. Start by finding every place the option is set, including authenticator stage configuration and any flow or policy that depends on it. Export your configuration before you change anything so you have a record of the original setting.
- Find the setting: Search your authenticator stage definitions and any configuration-as-code files for the option before the upgrade, and record which stages and flows use it.
- Confirm the post-upgrade behavior: Test in a staging instance on the target version how a user who already has a registered key is handled when they enroll the same key again.
- Plan user communication: Confirm with your own test results whether users will see a new prompt, an error, or a second credential, and draft a short message that explains what to do.
- Plan re-enrollment: If users need to re-register keys, schedule the change for a low-traffic window and decide who helps users who cannot sign in during that time.
- Record the decision: Note in your change record which accounts or groups were affected so auditors and help desk staff can trace the change.
Check the option search and the staging test results against the release notes before you publish any user guidance.
In authentik 2026.8, the hash_password command reads the password from a prompt or from standard input rather than from the command line argument pattern your scripts may use. Any automation that passes the password as an argument, or that assumes a particular output format, will need to change. This matters most for provisioning scripts, break-glass procedures, and runbooks that generate password hashes for configuration or for recovery.
- Inventory callers: Search CI pipelines, configuration management code, shell history templates, and runbooks for hash_password and record each call.
- Switch to stdin or a prompt: Update each caller to supply the password through standard input or an interactive prompt, and test the exact command on the target version.
- Keep secrets out of arguments: Confirm that your updated calls do not place plain text passwords in process arguments, logs, or shell history.
- Test output handling: Check that any script parsing the resulting hash still works with the output you observe on 2026.8.
- Update runbooks: Revise the documented recovery steps so an operator under pressure runs the new form, and retire the old examples.
Before you close the change, run each updated caller once in staging and confirm the hash it produces is accepted at login.
authentik 2026.8 rewrote the server entrypoint and the proxy outpost in Rust. For most deployments the change arrives through the image you pull, but any place where you override the container command, mount custom startup scripts, or pin outpost image tags needs a check. Because the entrypoint is different, a custom command that worked on earlier releases may fail to start the server or may skip steps you rely on.
- Confirm the images: Verify the server, worker, and outpost image tags you will deploy are the 2026.8 release, and that no older tag is pinned in Compose files or Helm values.
- Review entrypoint overrides: Check for any
command,entrypoint, or args settings in your Docker Compose or Kubernetes manifests and remove or adapt them against the release notes. - Check custom startup scripts: Identify wrapper scripts or init containers that call internal commands, and test them on the new image.
- Align outposts: Confirm each proxy outpost runs the matching 2026.8 image, since the proxy outpost has also changed.
- Test before production: Start a staging stack from the same manifests and confirm health, login, and forward auth work before you promote the change.
Review the 2026.8 release notes for the full list of entrypoint and outpost changes and compare them to your own manifests.
What makes a 2026.8 upgrade take longer
This table lists the factors that lengthen or shorten an authentik 2026.8 upgrade, with the direction each one pushes effort. Read each row as a question to answer about your own environment before you estimate the work, because the same release can be a short change for one deployment and a multi-week exercise for another.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Reverse proxy hops | Each proxy between clients and authentik must have its address listed in the trusted proxy CIDR setting, and every hop needs checking for forwarded headers | Map the full request path first and document each proxy's address range |
| Blueprints or scripts calling hash_password | The command now reads passwords from a prompt or stdin, so automation that passes arguments differently will fail | Inventory every job and rewrite calls before the upgrade window opens |
| WebAuthn policy usage | Policies that depended on the removed duplicate-device option need a replacement decision and retesting with registered passkeys | Find policies and flows that reference WebAuthn and decide their 2026.8 behavior in advance |
| Custom container entrypoints | The server entrypoint was rewritten in Rust, so wrappers, init scripts or overridden commands may no longer start the service | Compare your entrypoint overrides against the release notes and test startup in staging |
| Separately deployed outposts | Proxy outposts and other outposts need matching versions and their own config review, so each one adds a deployment and test cycle | Count outposts and confirm which can be upgraded together with the core |
| PostgreSQL configuration and backup size | Larger databases lengthen backup and restore checks, and custom connection settings may need review against the new defaults | Confirm a tested backup and restore path and record current database settings |
| Environments needing sign-off | Each environment, such as test, staging and production, usually needs its own change record, owner approval and rollback decision | Agree the sign-off sequence and evidence format before the first environment is changed |
Questions teams ask before upgrading authentik to 2026.8
Can our own team run the authentik 2026.8 upgrade without a partner?
Yes, if the team has someone comfortable with Docker Compose or Kubernetes, PostgreSQL backups and restores, and reverse proxy configuration. The release notes for 2026.8 change three things that need deliberate work: the trusted proxy CIDR setting, the hash_password command, and the Rust server entrypoint. Your team should read the authentik 2026.8 release notes line by line against your current configuration, test on a copy of production data, and confirm that every integration still signs users in before changing live traffic. A partner is useful when the team lacks that time or experience, or when the estate includes many applications, outposts and custom flows that need regression testing.
What drives the cost and effort of an authentik upgrade, and what should we ask for in a quote?
Effort follows the size of your authentik footprint rather than the version number alone. The main drivers are how many providers and applications depend on authentik, whether you run custom flows, policies or blueprints, how many outposts and reverse proxies sit in front of applications, how current your configuration is, and whether backups and a staging environment already exist. Costs are one-time for assessment, staging rehearsal, cutover and verification, and may recur if you retain support. Ask any provider for a written scope listing the configuration inventory, the environments covered, the test cases per application, the rollback procedure, the deliverables and the exclusions. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that scope.
Can we jump straight from an older authentik release to 2026.8?
Plan for a sequential path. authentik upgrades are expected to move through each release in order rather than skipping versions, so an older deployment has to step forward through the intermediate releases and their latest patches before reaching 2026.8. Each step can include database migrations and configuration changes that a later release assumes have already happened. Check the release notes for every version between your current release and 2026.8, and take a verified backup before each step. The page on catching up a version-lagged authentik covers the sequence in more detail. Confirm your exact path against the official release pages before you schedule any change window.
What breaks if the reverse proxy addresses are missing from the trusted proxy CIDRs?
From 2026.8, authentik reads forwarded headers only from networks listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. If your reverse proxy's address is not in that list, forwarded headers such as the client address and protocol are ignored. The practical symptoms include wrong client IP addresses in logs and policies that depend on them, GeoIP or reputation rules that evaluate the proxy instead of the user, redirect URLs built with the wrong scheme, and sign-in loops behind HTTPS termination. List every proxy address, including load balancers and ingress controllers in front of authentik, before upgrading. Then verify by signing in through each public hostname and checking the recorded client address in the event log.
How do we roll back if the 2026.8 upgrade fails?
The reliable rollback is a restore from a backup taken before the upgrade, not a downgrade of the software. Database migrations applied by a newer release may not be reversible by an older image, so the rollback plan should cover the PostgreSQL data, the uploaded media directory, and the exact image tags and configuration files in use before the change. Test the restore on a separate host, measure how long it takes, and record who can authorize it. Keep the previous container images available until the new version has run successfully through your normal sign-in and provisioning checks.
Do our outposts have to upgrade at the same time as the authentik core?
Outposts should stay on the same version as the core, so plan to upgrade them in the same change window. LDAP, RADIUS, proxy and RAC outposts communicate with the core, and a version mismatch can cause unexpected behavior. The 2026.8 release also rewrites the proxy outpost in Rust, so any proxy outpost image or deployment needs its tag updated and tested in the same step. Check outpost health and version in the admin interface after the change, and confirm that forward-auth applications and LDAP binds still succeed. The separate page on upgrading outposts describes the automatic and manual update options.
What does the upgrade need from our client team?
The work needs named people from identity, platform and application teams, plus access to the environment. Identity administrators confirm which providers, applications and flows matter and sign off test results. Platform engineers provide access to the Compose or Kubernetes deployment, the PostgreSQL instance, the reverse proxies and the backup system, and they approve the change window. Application owners test sign-in for their systems and report any claim or redirect-URI problems. Your team should also supply current configuration exports, a complete list of trusted proxy addresses, a staging environment that resembles production, and a documented rollback owner. Confirm these responsibilities in the written scope so that the upgrade does not stall while waiting for access.
How to test and roll back an authentik upgrade
Run the test cases in a staging copy of your authentik 2026.8 deployment before any production change, and treat the trusted proxy change as the first thing to verify. Log in through every protocol your estate uses, including OAuth2/OIDC, SAML, LDAP and any proxy or forward auth applications, and confirm each returns to the right application with the right claims. Enroll a test user in each second factor your policies allow, then sign in with it, because WebAuthn behavior changed in this release and enrollment flows are the easiest place to notice a regression. Check that LDAP binds succeed for service accounts and end users, since outposts and directory clients often fail quietly after a configuration change.
Pay particular attention to client IP in the logs. Because forwarded headers are now used only from networks listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, a missing reverse proxy address shows up as every login originating from the proxy, which breaks audit trails, GeoIP and reputation policies and any rate limiting that depends on the source address. Confirm the logged address for a test login from each network path, and confirm that policies keyed on IP still evaluate correctly. Also check the hash_password procedure in any runbook or script, since it now reads from a prompt or stdin.
Rollback should mean restoring a pre-upgrade backup of the PostgreSQL database and the uploaded files, then starting the previous image version against that restored data. Do not plan to downgrade the image on its own, because a database migrated by a newer release may not be read correctly by an older one. Take the backup immediately before the upgrade, verify it by restoring it into a separate instance, and record the exact image tags in use. Ask your team or DeployOpen to confirm, against the authentik 2026.8 release notes and the release notes for your current version, which restore steps, file locations and outpost versions each rollback requires before you rely on them.
How DeployOpen scopes and delivers authentik upgrades
DeployOpen plans the authentik 2026.8 upgrade as a written, fixed-scope piece of work: first the trusted proxy list and the WebAuthn and hash_password changes are inventoried against your deployment, then the upgrade is built and tested in a non-production copy before production. Each step ends with documented evidence that your sign-in flows still work.
How we scope
- We inventory every reverse proxy and load balancer address that forwards requests to authentik, so the trusted proxy CIDR list is complete before the upgrade.
- We check whether any WebAuthn registration policy depends on the removed Prevent duplicate devices option and document the replacement behavior.
- We identify scripts or runbooks that call hash_password and plan the change to prompt or stdin input for each one.
- Scope, deliverables and timelines are agreed in writing before work starts. Ongoing support is available as a retainer.
How we build
- We set AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS in a staging copy and test client IP, login and audit logs against real proxy paths.
- We rehearse the upgrade on a copy of your PostgreSQL data and confirm the server entrypoint change works with your container or Helm configuration.
- We test passkey and security key enrollment and sign-in for existing users, including the duplicate device behavior you rely on.
- We confirm the proxy outpost moves to the matching release and that outpost health reads correctly in the admin interface.
How we hand over
- You receive a written upgrade record covering the versions moved between, configuration changes, and test results.
- You receive an updated runbook with the trusted proxy list, rollback steps based on backup and restore, and the verification checklist.
- We walk your platform and security teams through the changed commands, configuration keys and WebAuthn settings.
- Configuration and documentation are stored in your repositories and infrastructure, so your team keeps full control.
How we support
- Post-upgrade checks cover sign-in, forwarded client addresses in logs, and outpost connectivity for the first business cycle after go-live.
- Security releases for the supported 2026.8.x line can be reviewed and applied under a retainer, since the project announces them at least 24 hours in advance.
- Upgrades to later releases are scoped separately so each one follows the sequential upgrade rule with its own tested steps.
- Confirm with DeployOpen which support level, response terms and testing cadence your retainer includes before signing.
