authentik vs Zitadel
Pick authentik if you want a full-featured self-hosted identity provider — SAML, LDAP, SCIM, and a proxy provider for apps that speak no protocol at all. Pick Zitadel if you're building your own product and want API-first, multi-tenant identity with passwordless as the default, and you're comfortable with AGPL.
Side by side
authentik and Zitadel are both modern, self-hostable identity providers built by teams who clearly looked at Keycloak and decided they could do better on UX. Past that, they are not really aiming at the same job. authentik is built to sit in front of the apps you already self-host and give them SSO — SAML, LDAP, a proxy provider for the ones that speak no protocol at all. Zitadel is built to be the identity layer inside something you're building — API-first, multi-tenant from day one, passwordless by default. Both are real options for a homelab or a small team. Which one is right depends on whether you're gating apps or shipping a product.
Gate your apps vs. power your product
authentik's centre of gravity is federation with existing software. Point an app that speaks OIDC, SAML, or LDAP at authentik and it works like any other identity provider; point an app that speaks nothing at authentik's proxy provider and it gets forward-auth protection instead. The admin experience — a visual, flow-based builder for assembling login steps — is designed for someone managing access to a portfolio of self-hosted services, not building a product on top of it.
Zitadel starts from a different premise: organizations and projects are first-class from the moment you deploy it. Every install is multi-tenant — you create organizations, each with its own users, apps, and policies — because Zitadel expects to be the auth backend for something you're shipping to your own customers, not just a login screen for tools you personally use. Its API-first design reflects that: nearly everything the admin UI can do, your code can do too, which matters if identity needs to be provisioned programmatically rather than clicked through by hand.
Both cover the OIDC/OAuth2/SAML core. Where they diverge is depth versus focus: authentik adds LDAP and SCIM and a proxy provider for apps with no native SSO support at all, spreading itself across more of the "gate my self-hosted stack" surface. Zitadel goes deep on one direction instead — passwordless and passkeys are the default sign-in path, not a bolted-on option, and multi-tenancy is architectural rather than a feature you enable.
Footprint
Both ship as multi-container Compose stacks, and neither is a lightweight install by self-hosting standards — but the gap between them is real. authentik's official stack runs a server, a background worker, PostgreSQL, and Redis, with a documented floor around 2 GB. Zitadel's quickstart is leaner — the binary, PostgreSQL, a login container, and a small proxy — with a 1 GB documented floor.
Measured idle at first boot confirms the direction, if not the exact ratio the floors suggest: a fresh authentik instance settles at ~516 MB, Zitadel at ~233 MB — both well under their documented minimums (which assume real traffic and warmed caches), but Zitadel's roughly 2x-lighter idle footprint tracks its simpler service graph. Neither number should be read as "install it and forget about RAM" — both grow with real usage — but on a small VPS that's already running the apps you're protecting, that gap is the difference between headroom and none.
Licensing: MIT core vs. AGPL
authentik's core is MIT, though the project follows an open-core model — an enterprise tier layers on remote access, risk detection, and support on top of a free edition that already covers OIDC, SAML, LDAP, SCIM, and the proxy provider for most self-hosters. Zitadel is AGPL-3.0, full stop. For a homelab or an internal tool that never leaves your network, AGPL's network copyleft clause is rarely a practical problem. It becomes one the moment you modify Zitadel and offer it as a network service to people outside your organization — at that point the license requires you to publish your modified source. If your use case is "self-host it for internal SSO," this is background noise. If your use case is "embed it in a product I sell," read the license text before you commit engineering time to it.
For homelab vs. for building a product
For a homelab or small self-hosted stack, authentik is the more natural fit precisely because that's the job it was built for — federate with the apps you run, proxy the ones that can't, and manage it all through one admin UI. Zitadel's multi-tenant organization model is overhead you'll never use if there's only ever one tenant: you.
If you're building a product that needs its own login system — a SaaS app, an internal platform other teams will build on — Zitadel's API-first design and built-in multi-tenancy stop being unused complexity and start being exactly the shape you need. authentik can technically be pressed into this role too, but you'd be working against its self-hosted-app-gateway design rather than with it.
Deployment difficulty splits the same way for a different reason: authentik rates 3 out of 5, Zitadel 4 out of 5. authentik's Compose file starts everything for you and the rest happens in a web UI; Zitadel asks you to think in organizations and projects from the first login, which is more conceptual overhead even though the container count is smaller.
Who should pick neither
If your actual requirement is simpler than either of these — passkey-only sign-in for a handful of self-hosted apps, no directory, no multi-tenancy — both authentik and Zitadel are more platform than the job needs. Pocket ID is a small, self-hostable OIDC provider built specifically for that case: passkeys only, one container, nothing to administer beyond the apps you point at it. See authentik vs. Pocket ID for the full comparison. And if all you need is a login gate in front of a reverse proxy with no real identity provider behind it, Tinyauth or Authelia do that in a fraction of the resources — see authentik vs. Tinyauth and Authelia vs. authentik.
Choosing between Zitadel and authentik
Flip the question around and it answers itself: are you provisioning identity for a product you're building, or are you gating a stack of self-hosted apps you already run? Zitadel's organizations, API-first design, and passwordless-by-default sign-in are the right primitives for the first case, and its measured ~233 MB idle footprint is genuinely lighter if you can live with AGPL. authentik's broader protocol coverage — LDAP, SCIM, and a proxy provider for apps with no SSO of their own — and its MIT-core, open-core licensing make it the safer default for the second case, which is what most self-hosters are actually doing. If you're not sure which describes you, you're probably gating apps, and authentik is the one to start with. Compare either against the enterprise incumbent in Keycloak vs. Zitadel and authentik vs. Keycloak.
Running either on a VPS
Both run comfortably on a single modest server, but size it to what each actually uses rather than the bare documented minimum: authentik for its full Compose stack (server, worker, Postgres, Redis), Zitadel for its Postgres-backed, event-sourced database — it's the source of truth for every identity you create, so back it up like it matters, because it does. Zitadel in particular needs a real database from the start; there's no dev-mode shortcut to skip that setup. Either stack fits comfortably on any of the VPS options here, and the step-by-step install guides are linked below.
Other comparisons with these apps
A tiny forward-auth gate vs. a full identity provider.
Modern and self-hoster-friendly vs. the enterprise standard.
A full identity platform vs. a passkey-only sign-in box.