2026.8.0 crash-loops on startup: TypeError in ensure_allowed_version() ("cannot use a string pattern on a bytes-like object")

[mudstrand]

Describe the bug

Upgrading a Docker Compose deployment from 2026.5.6 to 2026.8.0 causes both authentik-server and authentik-worker to crash-loop immediately on startup. The crash happens in the pre-migration version-skip check added in #24160 (ensure_allowed_version() in lifecycle/migrate.py):

TypeError: cannot use a string pattern on a bytes-like object
  File "/lifecycle/gunicorn.conf.py", line 164, in <module>
    run_migrations()
  File "/lifecycle/migrate.py", line 135, in run_migrations
    ensure_allowed_version(curr)
  File "/lifecycle/migrate.py", line 93, in ensure_allowed_version
    db_version = Version(cursor.fetchone()[0])
  File "/ak-root/.venv/lib/python3.14/site-packages/packaging/version.py", line 436, in __init__
    match = self._regex.fullmatch(version)

packaging.version.Version.__init__ calls a compiled re pattern's .fullmatch() against the value, which only accepts str, not bytes — hence the TypeError. This means cursor.fetchone()[0] (the version column from authentik_version_history) is coming back as bytes from the DB driver, even though the column itself is text:

                version   | pg_typeof
                -----------+-----------
                2026.5.6  | text
                2026.2.1  | text
                2025.12.4 | text
                2025.2.4  | text

(verified directly against the Postgres database — the authentik_version_history.version column is text, ruling out a schema/data issue.)

Both authentik-server and authentik-worker fail identically, since both run this same startup check, and neither ever becomes healthy — the whole deployment goes down.

How to reproduce

1. Run authentik 2026.5.6 via Docker Compose against an external PostgreSQL instance (not the bundled Postgres container — connecting to a separately managed Postgres host).
2. Confirm authentik_version_history has rows from prior upgrades (in our case: 2025.2.4 → 2025.12.4 → 2026.2.1 → 2026.5.6).
3. Bump the image tag to 2026.8.0 for both authentik-server and authentik-worker, docker compose up -d.
4. Both containers restart forever; docker logs authentik-server shows the traceback above.

Expected behavior

ensure_allowed_version() should read the version column as str (as the column type is text) and complete the version-skip check without crashing, allowing normal startup/migration to proceed.

Screenshots

No response

Version and Deployment (please complete the following information)

• authentik version: 2026.8.0 (upgrading from 2026.5.6)
• Deployment: Docker Compose
• Database: external, self-managed PostgreSQL (not authentik's bundled Postgres container)

Additional context

• Downgrading authentik_version back to 2026.5.6 and redeploying immediately restores a healthy authentik-server + authentik-worker, confirming this is specific to the 2026.8.0 startup path, not our Postgres instance or data.
• This may be related to how the DB connection is opened in run_migrations() / postgresql_direct_connection_kwargs(CONFIG) — possibly a binary-format cursor or similar — rather than anything in the schema itself, since the column is confirmed text at the database level.
• Happy to provide more log output, docker compose config, or test further if it helps narrow this down.

[gergosimonyi]

Can you please check server encoding on your postgres instance, e.g. via show server_encoding from within psql?

And if it's UTF8, can you please try the migration again with adding PGCLIENTENCODING=UTF8 to the environment?