Deploy Authentik — Self-Hosted SSO, OAuth2, SAML & LDAP
Self-host Authentik — SSO, OAuth2, SAML, LDAP & MFA identity
Authentik Server
Just deployed
/media
Authentik Worker
Just deployed
Just deployed
/var/lib/postgresql/data
Deploy and Host Authentik on Railway
Authentik is a full-featured, open-source identity provider — a self-hosted alternative to Okta, Auth0, and Azure AD that unifies OAuth2, OIDC, SAML, LDAP, SCIM, and MFA behind one login. Protect every app you run with single sign-on, enforce hardware-key or TOTP MFA from one policy, and add authentication in front of apps with no native SSO. This template deploys Authentik on its current architecture — server, worker, and PostgreSQL, with no separate Redis to run.
What This Template Deploys
| Service | Purpose |
|---|---|
| Authentik Server | API, SSO flows, and the web frontend (ports 9000/9443) |
| Authentik Worker | Background tasks — cert rotation, LDAP sync, event processing (same image, worker command) |
| PostgreSQL | All identity state — users, applications, flows, and configuration |
All three run on Railway's private network. Authentik runs the same image twice with different commands, and since version 2025.10 no separate Redis is required — a leaner stack than older setups.
About Hosting
Authentik has an architecture that catches people off guard, and its current version simplifies the stack in a way worth knowing.
It runs as two services from one image — you need both. Authentik splits into a server (API, SSO flows, frontend) and a worker (Celery background jobs: certificate rotation, LDAP sync, email, event processing), started from the same ghcr.io/goauthentik/server image with different commands. Deploy only the server and logins may work but background tasks silently don't — expiring certs, failing LDAP sync, no emails. This template runs both, wired to a shared PostgreSQL.
No Redis needed on current versions. Since Authentik 2025.10, the mandatory Redis dependency is gone — the minimum stack is PostgreSQL plus server and worker, three services instead of four. This template uses a current image, so you run and pay for one fewer service than older four-container setups, and all state lives in PostgreSQL, simplifying backups.
AUTHENTIK_SECRET_KEY signs everything — set it once and keep it. This key signs tokens and sessions. If it changes or is lost, recovery is painful and sessions break. Generate a long random value (openssl rand -hex 32), set it once, and back it up — don't rotate it casually.
Database config uses nested double-underscore variables. Authentik reads its Postgres settings as AUTHENTIK_POSTGRESQL__HOST, AUTHENTIK_POSTGRESQL__USER, and so on — the double underscore is significant. This template wires them from Railway reference variables so the server and worker both reach the database over the private network.
Set your domain and MFA policy after first login, and configure SMTP so users receive enrollment and recovery emails.
Typical cost: ~$10–15/month on Railway across the three services. Authentik is open source and free; Okta and Auth0 bill per user, which scales steeply.
How It Compares
| Authentik (self-hosted) | Okta / Auth0 | Keycloak | Logto | |
|---|---|---|---|---|
| Cost model | Flat infra | Per active user | Flat infra | Flat infra |
| Protocols | OAuth2, OIDC, SAML, LDAP, SCIM | All | All | OAuth2, OIDC, SAML |
| App proxy (no-code SSO) | Yes | Limited | No | No |
| Learning curve | Moderate | Managed | Steep | Gentle |
| Data ownership | Full | Vendor | Full | Full |
| Self-hostable | Yes | No | Yes | Yes |
Okta and Auth0 are polished but bill per user and hold your identity data. Keycloak is the established open-source option but has a steep learning curve. Authentik's edge is breadth with a gentler UX — OAuth2, SAML, LDAP, SCIM, MFA, and a built-in application proxy that adds SSO to apps with no native support, all self-hosted at infrastructure-only cost.
Deploy in Under 5 Minutes
- Click Deploy on Railway — server, worker, and PostgreSQL build automatically (~4 minutes)
- Confirm
AUTHENTIK_SECRET_KEYand the bootstrap password are set, and save them externally - Confirm the
AUTHENTIK_POSTGRESQL__*variables are wired to the database - Open the server domain and log in with the bootstrap admin credentials
- Set your domain, create applications and providers, and configure MFA policies and SMTP
The initial admin (akadmin) uses the bootstrap password; change it after first login.
Common Use Cases
- Centralize homelab login — one identity for Grafana, Nextcloud, Gitea, Jellyfin, and every self-hosted service
- Add SSO to internal tools — wire OAuth2 or SAML into company apps without building auth from scratch
- Replace Okta/Auth0 in SMBs — full IdP capabilities at infrastructure-only cost, no per-user billing
- Protect apps with no native SSO — the application proxy adds authentication in front of legacy apps
- LDAP and SCIM provisioning — act as an LDAP source and provision users into downstream services
Configuration
| Variable | Required | Description |
|---|---|---|
AUTHENTIK_SECRET_KEY | Required | Signs tokens and sessions — openssl rand -hex 32, set once and keep stable |
AUTHENTIK_POSTGRESQL__HOST | Auto-injected | PostgreSQL host via Railway reference variable |
AUTHENTIK_POSTGRESQL__USER | Auto-injected | Database user |
AUTHENTIK_POSTGRESQL__PASSWORD | Auto-injected | Database password |
AUTHENTIK_POSTGRESQL__NAME | Auto-injected | Database name |
AUTHENTIK_BOOTSTRAP_PASSWORD | Recommended | Initial password for the akadmin account |
AUTHENTIK_EMAIL__HOST | Recommended | SMTP server for enrollment and recovery emails |
AUTHENTIK_EMAIL__USERNAME / __PASSWORD | Recommended | SMTP credentials |
AUTHENTIK_SECRET_KEYmust stay stable. It signs all tokens and sessions; changing or losing it breaks sessions and makes recovery painful. Generate it once, back it up, don't rotate it casually.
You need both the server and the worker. They run from the same image with different commands. Without the worker, background tasks (cert rotation, LDAP sync, email) silently fail even though logins appear to work. Note the double-underscore in
AUTHENTIK_POSTGRESQL__*variables.
Dependencies for Authentik Hosting
- Railway account — ~$10–15/month across the three services
- PostgreSQL (included); no separate Redis required on current versions
- A domain or Railway subdomain for the identity provider
- SMTP credentials for enrollment and recovery emails
Deployment Dependencies
- Authentik GitHub Repository
- Authentik Documentation
- Configuration Reference
- Railway Private Networking
Implementation Details
The template runs two services from the ghcr.io/goauthentik/server image: the server (started with the server command, exposing ports 9000/9443 for the API, SSO flows, and frontend) and the worker (started with worker, running Celery background tasks like certificate rotation, LDAP synchronization, and event processing). Both connect to a shared Railway PostgreSQL service over the private network, with credentials supplied through Authentik's nested AUTHENTIK_POSTGRESQL__* variables.
Since Authentik 2025.10 the mandatory Redis dependency was removed, so the minimum stack is PostgreSQL plus server and worker — three services rather than four. All identity state lives in PostgreSQL, so the database is the single thing to back up, though it carries somewhat more connection load than the older Redis-backed architecture.
AUTHENTIK_SECRET_KEY signs tokens and sessions and must remain stable; AUTHENTIK_BOOTSTRAP_PASSWORD seeds the initial akadmin account. Authentik provides OAuth2/OIDC, SAML, LDAP, and SCIM providers plus an application proxy for forward authentication, configured through the web interface after first login.
Frequently Asked Questions
Why are there two Authentik services? Authentik splits into a server (API, SSO flows, frontend) and a worker (background tasks), run from the same image with different commands. Both are required — without the worker, things like certificate rotation, LDAP sync, and email silently stop working.
Do I need Redis? Not on current versions. Since Authentik 2025.10, Redis is no longer a mandatory dependency — this template runs PostgreSQL plus the server and worker, one fewer service than older setups.
Why is AUTHENTIK_SECRET_KEY important? It signs all tokens and sessions. If it changes or is lost, sessions break and recovery is difficult, so set it once with a long random value and keep it stable and backed up.
How does it compare to Keycloak? Similar protocol coverage (OAuth2, SAML, LDAP) but a gentler learning curve and a more modern interface, plus a built-in application proxy for adding SSO to apps without native support.
Does my identity data persist? Yes. All state lives in PostgreSQL, which persists across redeploys. Back the database up regularly, since it now holds everything.
How do I log in the first time? Use the akadmin account with the bootstrap password, then change it and configure your domain, applications, and MFA from the admin interface.
Why Deploy Authentik on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying Authentik on Railway you get a full identity provider with the architecture handled — server and worker correctly split, PostgreSQL wired, no separate Redis to run, the secret key set, and automatic HTTPS. SSO, MFA, OAuth2, SAML, and LDAP for every app you run, at infrastructure-only cost, on infrastructure you own.
Template Content
Authentik Server
ghcr.io/goauthentik/serverAUTHENTIK_BOOTSTRAP_EMAIL
Initial admin email for bootstrap
AUTHENTIK_BOOTSTRAP_PASSWORD
Initial admin password first boot
Authentik Worker
ghcr.io/goauthentik/server
