authentik: The Self-Hosted Identity Provider That Kills Your Per-User Auth Bill

"Every self-hosted app with its own password is a small liability. Multiply by thirty and you have a security program built on hope."

Here's a pattern every self-hoster recognizes. You run Meilisearch with no authentication, changedetection.io with a single shared password, Gitea with local accounts, Grafana with its own user table, and a handful of internal tools with nothing at all. Each has its own login, its own password policy, its own forgotten-password flow, and its own chance of being left on default credentials. Offboarding a teammate means remembering all thirty. authentik (GitHub: goauthentik/authentik) is the open-source fix: a real identity provider you run yourself. As of August 2026 it carries roughly 25,000 stars, is licensed MIT for the core, ships as version 2026.8.1, and speaks OIDC, OAuth2, SAML, LDAP, and SCIM. Built on Python/Django with Go and Rust components, it's the piece that turns thirty separate logins into one — with the credentials stored on your hardware rather than billed per user by a vendor. This is the honest breakdown: what an identity provider actually does (and how it differs from simpler proxy auth), the deployment walkthrough, what it costs versus Auth0 or Okta, and the operational weight you're taking on.

1. The Distinction That Confuses Everyone: IdP vs Proxy Auth

Before choosing anything, understand this split — it's the most common source of misconfiguration. Proxy authentication (Authelia, and Traefik's ForwardAuth middleware) sits in front of an application. You visit app.example.com, the proxy checks whether you have a valid session cookie, and if not it shows a login page. The application itself knows nothing about who you are. This is excellent for protecting apps that have no authentication of their own. An identity provider (authentik, Keycloak, Zitadel) issues actual OIDC tokens and SAML assertions. Applications that support SSO — Gitea, Grafana, Nextcloud, Outline, Miniflux — consume those tokens and know your identity, groups, and attributes. The practical test: if the app has "Sign in with OIDC/SAML" in its settings, you need an IdP, not proxy auth. Proxy auth can't do that job, because it has no token to issue. authentik actually does both — it's an IdP and it ships outposts that act as proxy authenticators for legacy apps. That dual capability is its main architectural advantage, and it's why many homelabs end up running authentik where they'd otherwise need two tools.

2. What You Get: Protocols and Capabilities

• OIDC / OAuth2 — the modern standard, supported by nearly every current self-hosted app.
• SAML 2.0 — still mandatory for plenty of enterprise SaaS.
• LDAP — both as an outpost for apps that only speak LDAP, and for federation.
• SCIM — user provisioning and deprovisioning, so offboarding is one action.
• Passkeys / WebAuthn — passwordless MFA, which is both more secure and less annoying than TOTP.
• Social login — GitHub, Google, Discord, and others via OAuth2 sources.
• A visual flow engine — authentication sequences built as customizable pipelines.

That last item deserves elaboration, because it's what makes authentik feel different from its competitors.

3. The Flow Engine

In most identity systems, customizing the login experience means writing code or fighting a config file. In authentik, an authentication sequence is a flow: a graph of stages connected in the admin UI. A flow might be: identify user → check password → if MFA enrolled, prompt for WebAuthn → if not, prompt for TOTP → check group membership → issue token. Each stage is configurable, each binding is visible, and you can build enrollment flows, password recovery flows, and invitation flows the same way. The upside is extraordinary flexibility without code. The downside is that flows are the learning curve. New users break authentication regularly by editing a flow they don't fully understand. The defense is simple: don't edit the default flows until you've read the docs, and always keep a break-glass admin account that bypasses your customizations.

4. Outposts: The Genuinely Different Feature

Most apps you self-host fall into two buckets: those that speak OIDC, and those that don't. Meilisearch, changedetection.io, and many small tools have no SSO support at all — or hide it behind a paywall. authentik's outposts solve this. A proxy outpost is a lightweight component that sits in front of an application, authenticates the user against authentik, and forwards identity headers. The application sees an authenticated request without knowing or caring how authentication happened. There are outposts for LDAP, RADIUS, and proxy scenarios. The architectural nicety is that outposts can be deployed near the applications they protect, so authentication latency stays low and you're not hairpinning every request back to a central server. This is why authentik is a strong fit for heterogeneous environments — the realistic case where you have modern apps with OIDC, legacy apps with LDAP, and simple web tools with nothing.

5. Self-Hosting authentik: The Walkthrough

authentik is not a single container. It's four: server, worker, PostgreSQL, and Redis. Accept that from the start. ``yaml services: postgresql: image: docker.io/library/postgres:16-alpine restart: unless-stopped healthcheck: test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"] interval: 30s retries: 5 volumes: - ./database:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: ${PG_PASS:?database password required} POSTGRES_USER: authentik POSTGRES_DB: authentik redis: image: docker.io/library/redis:alpine command: --save 60 1 --loglevel warning restart: unless-stopped volumes: - ./redis:/data server: image: ghcr.io/goauthentik/server:2026.8.1 restart: unless-stopped command: server environment: AUTHENTIK_REDIS__HOST: redis AUTHENTIK_POSTGRESQL__HOST: postgresql AUTHENTIK_POSTGRESQL__USER: ${PG_PASS:?} AUTHENTIK_POSTGRESQL__NAME: authentik AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS:?} AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?} AUTHENTIK_HOST: https://auth.example.com AUTHENTIK_EMAIL__HOST: smtp.example.com AUTHENTIK_EMAIL__USER: [email protected] AUTHENTIK_EMAIL__PASSWORD: ${SMTP_PASS:?} AUTHENTIK_EMAIL__USE_TLS: "true" volumes: - ./media:/media - ./certs:/certs ports: - "9000:9000" - "9443:9443" worker: image: ghcr.io/goauthentik/server:2026.8.1 restart: unless-stopped command: worker environment: AUTHENTIK_REDIS__HOST: redis AUTHENTIK_POSTGRESQL__HOST: postgresql AUTHENTIK_POSTGRESQL__USER: ${PG_PASS:?} AUTHENTIK_POSTGRESQL__NAME: authentik AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS:?} AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?} volumes: - ./media:/media - ./certs:/certs ` Deployment notes that save real time:

• Generate a proper AUTHENTIK_SECRET_KEY — at least 50 characters of random data. Regenerating it invalidates existing sessions and encrypted data.
• Use the same version tag for server and worker. Mismatched versions cause subtle, maddening failures.
• Pin the version. Never use :latest for an identity system.
• AUTHENTIK_HOST must be your real external URL. Wrong value produces redirect loops — the single most-reported first-run problem.
• Configure email before you need it. Password resets and invitations depend on it, and debugging SMTP inside a container is unpleasant.
• Give it RAM. Realistic idle is roughly 800 MB to 1 GB across all components; plan 2 GB minimum, 4 GB comfortably.
• Put it behind TLS. Port 9000 is the HTTP entrypoint, 9443 the HTTPS one, but most people terminate at a reverse proxy instead.
• Back up Postgres and ./media. Together they are your entire identity system.

6. The Honest Limitations

It's four services, not one. Compared to a single-binary tool, this is meaningfully more operational surface. Four containers to upgrade, monitor, and back up. Memory footprint is real. Around 1 GB idle is a lot for a homelab running on a small VPS. If you have 2 GB total, this will crowd out everything else. The flow engine is a footgun. Powerful, but easy to lock yourself out of. Always keep a recovery path. Enterprise features are paid. The core is MIT and covers most needs, but FIPS 140 readiness, mTLS, and support SLAs sit behind commercial tiers. If you have compliance requirements, check which tier you need before you build on it. It's overkill for small setups. Three apps and two users do not need an identity provider. This is the most important limitation and the one enthusiasts skip. Identity is a single point of failure. If authentik goes down during a workday, nobody can log into anything. That argues for treating it as tier-zero infrastructure: monitored, backed up, and restart-tested. Upgrades require attention. Read release notes before jumping versions. Identity systems are not where you want surprises.

7. What It Actually Costs

The comparison that justifies the whole exercise: | Option | Cost at 50 users | Notes | |---|---|---| | Auth0 Essentials | ~$240+/month | Scales with MAU; enterprise features cost more | | Okta | ~$850+/month | $17–25/user/month at the low end | | authentik self-hosted | ~$0 license | Unlimited users, unlimited applications | Infrastructure for authentik: | Item | Cost | |---|---| | authentik license | $0 (MIT core) | | VPS (2–4 GB RAM) | ~$15–30/month | | Backups | ~$2–5/month | | Total | ~$17–35/month | At 50 users that's roughly $0.50 per user per month versus $17–25 — a 30–50x difference that widens as you grow. The honest counter-argument: you're trading dollars for operational responsibility. If authentik breaks at 2 a.m., you are the support contract. For a business whose compliance posture requires a vendor SLA, the SaaS bill may genuinely be the rational choice. For a homelab or a small team already running self-hosted infrastructure, it isn't close.

8. Where Your Data Lives

Self-hosted authentik has one of the cleanest sovereignty stories of any infrastructure component, because identity data is among the most sensitive you hold:

• User records, credentials, group memberships → your PostgreSQL, on your disk.
• Sessions → your Redis, in your control.
• Audit logs → your database, queryable and exportable by you.
• Authentication flows → never leave your network. A login against your authentik produces no outbound call.

Compare with a SaaS IdP, which necessarily sees every login: who, when, from where, to which application, with which MFA method. That's a complete map of organizational behavior sitting in a third party's systems. One caveat: if you configure social login sources (GitHub, Google), the initial federated login does contact those providers. That's the nature of federation, not a leak — but know it's happening and decide deliberately which sources to enable.

9. authentik vs Keycloak vs Authelia vs Pocket ID

| | authentik | Keycloak | Authelia | Pocket ID | |---|---|---|---|---| | Type | Full IdP | Full IdP | Proxy auth only | Lightweight IdP | | License | MIT | Apache-2.0 | Apache-2.0 | BSD-2-Clause | | Language | Python + Go + Rust | Java (Quarkus) | Go | Go | | RAM (recommended) | 2 GB | 4 GB+ | 256 MB | 512 MB–1 GB | | SAML | Yes | Yes (most complete) | No | No | | LDAP/AD | Yes | Yes (best) | No | No | | Passkeys | Yes | Yes | Yes | Yes (passkey-only) | | Admin UI | Excellent | Complex | Basic | Simple | | Proxy for legacy apps | Yes (outposts) | Via reverse proxy | Native | No | | Setup complexity | Medium | High | Low | Low | The decision rule that actually works:

• Homelab, a few simple apps, want 2FA → Authelia. Far lighter, much simpler.
• Team, mixed modern and legacy apps, want one nice UI → authentik. This is its sweet spot.
• Enterprise with Active Directory and complex SAML → Keycloak. Heavier, but the AD integration is best-in-class.
• Everyone can use passkeys, minimal footprint → Pocket ID. Deliberately limited: no SAML, no LDAP, no passwords.

authentik's edge is that it covers the broad middle ground better than anything else — full IdP capability without Keycloak's weight, plus outposts so legacy apps aren't left behind.

10. Who Should Not Self-Host authentik

• You have fewer than five apps and three users. Genuinely not worth it. Use Authelia or basic auth.
• You have 2 GB of RAM total. It will crowd out everything else.
• You need a vendor SLA for compliance. Buy a service, or buy authentik's commercial tier.
• You won't maintain it. An unmaintained identity provider is a locked door you've lost the key to — the worst failure mode in self-hosting.
• You need enterprise AD federation. Keycloak is the better tool.

Backups and Disaster Recovery: Your Identity System Is Tier Zero

Most self-hosted services degrade gracefully. If your media server goes down, movie night is cancelled. If your identity provider goes down, nobody can log into anything — including the tools you'd use to fix it. That makes authentik tier-zero infrastructure, and it changes how you should treat it. What to back up:

• PostgreSQL — users, credentials, groups, applications, providers, flows, audit logs. The core.
• ./media — uploaded icons, background images, and any file assets.
• ./certs — certificates used by outposts.
• Your environment file and AUTHENTIK_SECRET_KEY — without the secret key, a restored database is unreadable. This is the item people lose. Store it in your password manager, not just on the host.

What "recovery" looks like: restore the database dump, restore the media volume, restore the secret key, bring the stack up, and confirm you can log in as admin and that at least one application accepts a token. Do that drill once, deliberately, on a spare host before you depend on authentik for anything important. Identity systems have a nasty property: they usually work fine for months and then fail catastrophically in a way that requires exactly the access you've just lost. Finally, monitor it. authentik should be in your Uptime Kuma or Grafana alerting with the same severity as anything else — arguably higher.

Gotchas Worth Knowing Before You Start

A short list compiled from the mistakes people actually make:

• Redirect loops after first login. Almost always a wrong AUTHENTIK_HOST or a reverse proxy not forwarding the correct Host and X-Forwarded-Proto` headers. Check headers before you blame the flows.
• Locked out by a flow edit. Always keep a second admin account whose authentication path you haven't customized.
• Email silently broken. Password resets appear to succeed but never arrive. Test SMTP at deploy time.
• Server and worker version mismatch. Pin both to the same tag, always.
• Secret key regenerated by accident. Invalidates sessions and encrypted fields. Generate once, store safely, never regenerate casually.
• Outposts stop working after a version bump. Outposts are versioned too; upgrade them alongside the server.
• Assuming proxy outposts replace app-native SSO. They don't — use native OIDC where the app supports it, and reserve outposts for apps that have no alternative.

What Actually Changes Once You Have SSO

It's worth naming the payoff concretely, because "centralized authentication" sounds like plumbing. Onboarding becomes one action. Create a user, assign groups, and every connected application grants access according to those groups. No per-app account creation, no spreadsheet of who has access to what. Offboarding becomes one action. Deactivate the user and access is revoked everywhere simultaneously. Without an IdP, this is the step that gets missed — and a former colleague retaining access to an internal tool is exactly the quiet risk that compounds. MFA becomes universal. Instead of hoping each app has 2FA and that everyone enabled it, you enforce it once at the identity layer. Applications that have no MFA support of their own inherit it. Password policy becomes real. One place to set length, rotation, and breach checks, applying to every app regardless of whether that app has its own policy settings. Audit becomes possible. One log answering "who accessed what, when" across the stack — a question that is essentially unanswerable when each app keeps its own. That's the case. It's unglamorous, and it's the difference between a pile of services and something you can responsibly hand to a team.

11. Getting Started Without Locking Yourself Out

A safe first-day sequence: 1. Deploy the four containers with pinned versions and a real secret key. 2. Complete the initial admin setup, then immediately create a second admin account and store its credentials outside authentik. 3. Configure and test email before onboarding anyone. 4. Connect exactly one application — pick the one you use most, ideally Grafana or Gitea, both of which have clean OIDC support. 5. Confirm you can still log in with local credentials while OIDC is enabled. Do not disable local login yet. 6. Only after several days of stability, add the second app. Then the third. 7. Set up automated Postgres backups and do one restore test before you depend on it. The recurring disaster story is step 5: someone disables local login, breaks a flow, and locks out every account including admin. Don't be that person.

12. The Verdict

authentik is the most approachable serious identity provider in the self-hosted world. The MIT license is genuinely permissive, the admin interface is genuinely good, the flow engine is genuinely powerful, and outposts solve the legacy-app problem that most IdPs ignore. The economics are decisive if you have more than a handful of users: unlimited applications and unlimited users on a fixed infrastructure bill, against per-MAU SaaS pricing that punishes growth. And the sovereignty case is unusually strong — identity data is the last thing you want logged by a third party, and self-hosting means nobody sees who logged into what, when. The caveats are straightforward. It's four services rather than one, it wants 2 GB of RAM, the flow engine will bite you if you're careless, and it is honest overkill for small setups. None of those are reasons to avoid it — they're reasons to know what you're signing up for. If you're running more than a dozen self-hosted apps with shared passwords and no central offboarding, authentik is the piece that turns a collection of services into something resembling a platform. Start with one app, keep the break-glass admin, and expand deliberately.

Related

• Traefik: The Reverse Proxy That Configures Itself While You Sleep — where authentik's proxy outposts slot into your routing layer.
• Headscale: The Open-Source Tailscale Control Server That Puts Your Mesh VPN Back in Your Hands — network-level access control; authentik is the application-level counterpart.
• Grafana: The Self-Hosted Observability Layer That Turns Your Metrics Into Answers — one of the best first apps to connect via OIDC.