goauthentik
Fresh Install Not Creating authentik_install_id table
Describe the bug I am spinning up a fresh install of authentik 2025.8.4. On first boot, the server runs migrations but never goes live because it does not create the authentik_install_id
To Reproduce Steps to reproduce the behavior:
Start a fresh install of authentik with postgres 17.
Expected behavior The server should go healthy so I can activate the instance.
Screenshots If applicable, add screenshots to help explain your problem.
Logs
{
"event": "Internal Server Error: /-/health/live/",
"exception": [
{
"exc_notes": [],
"exc_type": "ProgrammingError",
"exc_value": "relation \"public.authentik_install_id\" does not exist\nLINE 1: SELECT id FROM public.authentik_install_id ORDER BY id LIMIT...\n ^",
"exceptions": [],
"frames": [
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/core/handlers/exception.py",
"lineno": 55,
"name": "inner"
},
{
"filename": "/authentik/events/middleware.py",
"lineno": 154,
"name": "__call__"
},
{
"filename": "/authentik/enterprise/audit/middleware.py",
"lineno": 29,
"name": "connect"
},
{
"filename": "/authentik/enterprise/audit/middleware.py",
"lineno": 25,
"name": "enabled"
},
{
"filename": "/authentik/enterprise/apps.py",
"lineno": 24,
"name": "enabled"
},
{
"filename": "/authentik/enterprise/apps.py",
"lineno": 30,
"name": "check_enabled"
},
{
"filename": "/authentik/enterprise/license.py",
"lineno": 234,
"name": "cached_summary"
},
{
"filename": "/authentik/enterprise/license.py",
"lineno": 133,
"name": "get_total"
},
{
"filename": "/authentik/enterprise/license.py",
"lineno": 52,
"name": "get_license_aud"
},
{
"filename": "/authentik/tenants/utils.py",
"lineno": 20,
"name": "get_unique_identifier"
},
{
"filename": "/authentik/root/install_id.py",
"lineno": 28,
"name": "get_install_id"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/backends/utils.py",
"lineno": 79,
"name": "execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/backends/utils.py",
"lineno": 92,
"name": "_execute_with_wrappers"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/backends/utils.py",
"lineno": 100,
"name": "_execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/utils.py",
"lineno": 91,
"name": "__exit__"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/backends/utils.py",
"lineno": 103,
"name": "_execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django_prometheus/db/common.py",
"lineno": 69,
"name": "execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/psycopg/cursor.py",
"lineno": 97,
"name": "execute"
}
],
"is_cause": false,
"is_group": false,
"syntax_error": null
},
{
"exc_notes": [],
"exc_type": "UndefinedTable",
"exc_value": "relation \"public.authentik_install_id\" does not exist\nLINE 1: SELECT id FROM public.authentik_install_id ORDER BY id LIMIT...\n ^",
"exceptions": [],
"frames": [
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django/db/backends/utils.py",
"lineno": 103,
"name": "_execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/django_prometheus/db/common.py",
"lineno": 69,
"name": "execute"
},
{
"filename": "/ak-root/.venv/lib/python3.13/site-packages/psycopg/cursor.py",
"lineno": 97,
"name": "execute"
}
],
"is_cause": true,
"is_group": false,
"syntax_error": null
}
],
"level": "error",
"logger": "django.request",
"timestamp": "2025-10-09T03:14:19.585570"
}
Version and Deployment (please complete the following information):
- authentik version: 2025.8.4
- Deployment: helm on k3s
Additional context
Things I've tried:
- use the previous release of authentik
- create the table manually myself
- use a different schema besides public (this failed for other reasons)
- grant superuser perms to the authentik pg user
That table is created by https://github.com/goauthentik/authentik/blob/main/lifecycle/system_migrations/install_id.py, do you have the logs from the start of the container? Does it try to run that migration and fail?
Yeah, the migration shows as running:
{"event": "Finished authentik bootstrap", "level": "info", "logger": "authentik.lib.config", "timestamp": 1760021392.1163533}
2025-10-09 14:49:52 [info ] waiting to acquire database lock
2025-10-09 14:49:52 [info ] Migration needs to be applied migration=install_id.py
2025-10-09 14:49:52 [info ] Migration finished applying migration=install_id.py
2025-10-09 14:49:52 [info ] Migration needs to be applied migration=template_schema.py
2025-10-09 14:49:52 [info ] Migration finished applying migration=template_schema.py
2025-10-09 14:49:52 [info ] Migration needs to be applied migration=tenant_files.py
2025-10-09 14:49:52 [info ] Migration finished applying migration=tenant_files.py
2025-10-09 14:49:52 [info ] Migration needs to be applied migration=version_history_create.py
2025-10-09 14:49:52 [info ] Migration finished applying migration=version_history_create.py
2025-10-09 14:49:52 [info ] Migration needs to be applied migration=version_history_update.py
2025-10-09 14:49:52 [info ] Migration finished applying migration=version_history_update.py
2025-10-09 14:49:52 [info ] applying django migrations
{"event": "Booting authentik", "level": "info", "logger": "authentik.lib.config", "timestamp": 1760021392.46845, "version": "2025.8.4"}
No errors though
Here's the full boot log:
I was able to track this down by looking at the tables in psql and I identified that the python migrations were creating tables in the authentik schema and not the public schema.
I set default_schema to authentik and that got everything working properly. There's a bug here where the python migrations are using the wrong schema (I tried setting default_schema to public but that didn't work), but I'm no longer blocked.
# values.yaml
authentik:
postgresql:
default_schema: authentik
@oliverisaac It is mentioned here that the search_path needs to be set to the schema authentik is configured to use: https://docs.goauthentik.io/install-config/configuration/#advanced-settings
However the PR above also fixes this issue by setting the path correctly for system migration