External Proxy Outpost ignores Session/State persistence (Redis/Postgres) -> Filesystem fallback cau

[YouKyi]

Description: Hello, I am facing a critical stability issue with the External Proxy Outpost (Docker). I cannot get the Outpost to persist its state/sessions externally. It stubbornly falls back to filesystem storage no matter what configuration I apply.

The Consequence: Because the Outpost defaults to filesystem, every time the container restarts (update or config change), the internal state is wiped. If a user is in the middle of an auth flow (or just performing a callback), the Outpost rejects the request with an HTTP 400 Bad Request (likely due to "Invalid State" or missing session reference), rendering the service unusable until cookies are cleared or a fresh login flow is started.

My Setup:

• Version: Authentik Proxy 2025.12 (Docker)
• Deployment: Docker Compose (via Komodo)
• Architecture: External Proxy Outpost (Single container + Redis sidecar)

What I have tried (and failed):

1. Attempt with Redis (Preferred method) I configured the Proxy with a dedicated Redis container.

• Env Var: AUTHENTIK_REDIS__HOST=redis
• Network: Both containers are on the same bridge network.
• Result: The logs explicitly state using filesystem session backend. The variable seems completely ignored or the connection fails silently without a clear error message explaining why it dropped to filesystem.

2. Attempt with PostgreSQL (Confusion) I tried providing the Postgres variables (POSTGRES_HOST, POSTGRES_PASSWORD, etc.) to the proxy container, assuming it might work like the Core server.

• Result: On startup, I get warnings like env_var=POSTGRES_PASSWORD event=Environment variable not found, using fallback.
• This is very confusing: the variables are passed in the Compose file, but the entrypoint script claims they are missing, and ultimately the Proxy still falls back to filesystem.

3. Header Size I also added AUTHENTIK_WEBSERVER__MAX_HEADER_SIZE=32k to rule out header size issues, but the root cause is clearly the loss of state upon restart.

Logs (Evidence):

# Despite AUTHENTIK_REDIS__HOST being set:
INF | event=using filesystem session backend logger=authentik.outpost.proxyv2 timestamp=...

# During the callback after a restart (The 400 error):
INF | event=/outpost.goauthentik.io/auth/traefik ... status=302 ...
INF | event=/outpost.goauthentik.io/auth/traefik ... status=400 ...

Docker compose:

Docker compose with Postgres, and the same warning at the starting up “warning | env_var=POSTGRES_PASSWORD event=Environment variable not found, using fallback fallback= found=false timestamp=2026-02-04T20:48:25+01:00 “ :

https://cdn.youkyi.fr/u/qKMfN0.yaml

Modified Docker compose with Postgres without the error at the startup :

https://cdn.youkyi.fr/u/gN5dzo.yaml

Docker compose with redis :

https://cdn.youkyi.fr/u/4Z7Y8o.yaml

In all case, i have this in log “INF | event=using filesystem session backend logger=authentik.outpost.proxyv2 timestamp=...”

I did some further debugging inside the running proxy container to see exactly where these sessions are landing since Redis is being ignored.

I found that the proxy is creating session files in /dev/shm:
Plaintext

I have no name!@authentik-int:/dev/shm$ ls
session_7SISASK... session_RFCLJ2...

My Conclusion: Technically, I realize I could force persistence by mounting a Docker volume directly to /dev/shm. This would likely solve the data loss on restart and the subsequent 400 errors.

However, I strongly refuse to implement this. Mounting a persistent disk volume over /dev/shm (which is designed for volatile shared memory) is a dirty hack ("hacky workaround") and not a proper production solution.

This finding confirms 100% that the Proxy is defaulting to its internal fallback despite the AUTHENTIK_REDIS__HOST variable being present. Please assist in understanding why the Redis configuration is being completely bypassed by the application.

Question: How can I force the External Proxy Outpost to strictly use Redis (or Postgres if applicable now) and crash if it fails, rather than silently falling back to filesystem? I need the authentication state to survive a container restart to avoid these constant 400 errors for my users.