authentik vs Zitadel: which to choose

authentik vs Zitadel: when each platform fits

If your users are employees and your apps sit behind a reverse proxy or speak LDAP and RADIUS, authentik fits internal IT best. If you are building a product whose customers each need their own users, identity providers and administrators, Zitadel fits multi-tenant products better. Both are self-hosted OpenID Connect and SAML providers, so the choice turns on the work you need the platform to do, not on a feature checklist. Start with license terms for your use. authentik core is MIT licensed, but code under authentik/enterprise needs a paid subscription for production use, so confirm which features your environment needs and whether they sit in the free or Enterprise code. Zitadel was relicensed to AGPL-3.0-only with v3 in March 2025, while its APIs, SDKs and Helm charts remain Apache 2.0. Ask your legal team how AGPL obligations apply if you modify and offer the service over a network, and read the Zitadel licensing overview before deciding.

Next, list the protocols and directory integrations you must support on day one. authentik provides LDAP, RADIUS and proxy providers through its outposts, which suits legacy applications and forward authentication for apps with no native SSO. Zitadel focuses on OIDC, OAuth 2.0, SAML 2.0, SCIM and federation to upstream providers, and it lacks an equivalent proxy outpost, so confirm any LDAP or RADIUS requirement with the vendor before you commit. Then decide whether each customer needs its own organization with separate identity providers, since that is the core Zitadel model. Finally, decide who operates the platform. authentik runs as a server and worker container backed by PostgreSQL, and Zitadel needs PostgreSQL 14 to 18 and a plan for high availability, so have your platform team confirm it can own that stack and any paid support tier.

authentik vs Zitadel for internal IT and customer apps

This table compares authentik and Zitadel by scenario and names the fact behind each fit. Read each row as the condition under which one platform is the stronger starting point. Both cover core single sign-on needs, so the deciding factors are usually tenancy, licensing and audit requirements.

Scenario	Better fit	Why
Internal workforce SSO with LDAP or RADIUS clients	authentik	LDAP and RADIUS are both authentik providers, managed through its admin interface and outposts. Confirm RADIUS coverage in Zitadel before deciding.
Protecting legacy apps behind a reverse proxy	authentik	The proxy provider runs through the embedded outpost, which suits apps without OIDC or SAML support. Confirm Zitadel's options for this pattern.
SaaS product where each customer manages its own users	Zitadel	Organizations inside one instance map to customer tenants, and each customer can administer its own users and projects.
B2B apps needing a per-customer identity provider	Zitadel	Each customer organization can federate login to a different identity provider, including OIDC, SAML and LDAP sources.
Teams that must avoid AGPL-3.0 obligations on modified code	authentik	authentik core is MIT, but enterprise code uses a separate paid license. Zitadel core has been AGPL-3.0 since v3.0. Confirm obligations with counsel.
Teams that want a full event history of identity changes	Zitadel	Event sourcing stores every change as an event, giving a built-in audit trail. authentik's enhanced audit logging is an Enterprise feature.

How authentik and Zitadel are built and deployed

authentik and Zitadel both keep their state in PostgreSQL, but they differ in how many moving parts they run and how they model tenants. The cards below cover the components, the database versions, the Redis change and the tenant model, with the checks to run before you commit to either one.

authentik server, outpost and worker

A standard authentik deployment runs a server container that includes the core application and an embedded outpost, plus a separate worker container for background tasks. Both containers depend on PostgreSQL, which holds all configuration and data except uploaded files. For day-two work, this means an upgrade touches two application containers and one database. Confirm in your own environment how you will roll the server and worker together and where you will keep backups of the database.

Redis removed in 2025.10

The authentik 2025.10 release notes state that authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket functions to PostgreSQL. The same notes warn of roughly 50% more PostgreSQL connections after upgrading. If you are moving from an older authentik with Redis, plan connection limits and pooling before cutover, and load test the upgrade in a staging copy of your database. Zitadel does not depend on Redis in the same way, so the comparison here is about connection planning for authentik specifically.

Zitadel instances, organizations and projects

Zitadel groups tenants in three layers: instances, which are virtual tenants with full data isolation; organizations inside an instance, where projects and users live; and projects, which group applications, roles and grants. This model suits B2B products where each customer manages its own users. Before choosing it for internal IT, confirm that your team is comfortable designing this hierarchy, because a directory-style layout with one shared user population maps less directly onto it.

Zitadel deployment paths

Self-hosted Zitadel documents three deployment routes: Linux and macOS binaries, Docker Compose, and Kubernetes. For high availability, Zitadel recommends a Kubernetes cluster with the official Helm chart. A single-host Compose setup is simpler to run but offers less redundancy. Ask your platform team which route matches your availability target, and confirm who will own the Helm chart values and upgrade path over time.

PostgreSQL 14 to 18 on both

Both authentik and self-hosted Zitadel run on PostgreSQL, and both document support for versions 14 through 18. This narrows the database choice, but it does not remove the work. Confirm that your managed or on-premises PostgreSQL service is on a supported version, check the backup and restore process for each product, and agree who is responsible for minor version patches. Reviewing these together helps you avoid a database that is outside the supported range at go-live.

authentik vs Zitadel capabilities side by side

This table compares protocol, directory, outpost, provisioning, passkey, tenancy and licensing capabilities of authentik and Zitadel. Where a row says to confirm, the feature is not documented clearly enough to rely on, so check the vendor documentation or run a test deployment before deciding. Treat each gap as a question to put to the vendor, and weigh the rows that match how your users and applications actually sign in.

Capability	authentik	Zitadel
OIDC, OAuth 2.0 and SAML 2.0 support	Provides OAuth2/OIDC and SAML providers in the core edition	Implements OpenID Connect, OAuth 2.0 and SAML 2.0
LDAP	Offers an LDAP provider; confirm the bind and search behavior your applications need	Federates login from LDAP and OpenLDAP as an upstream provider; confirm whether you need Zitadel to serve LDAP
RADIUS	Offers a RADIUS provider for network access use cases	Not listed among documented capabilities; confirm with Zitadel before relying on it
Proxy and forward-auth outposts	Proxy provider runs through the embedded outpost to protect apps behind a reverse proxy	Not a documented capability; confirm if you need forward auth for legacy apps
SCIM provisioning	Listed as a provider type; confirm direction, scope and edition on the providers page	SCIM v2 service provider interface for standardized user provisioning and lifecycle management
Passkeys and WebAuthn	Confirm passkey and WebAuthn options in your authentication flows	Passkeys based on FIDO2 and WebAuthn, with fallback to password login
Device authorization grant	Confirm support before relying on it for TVs or input-limited devices	Provides a device authorization grant for devices such as smart TVs
Multi-tenancy and audit history	Single-instance model on PostgreSQL; enhanced audit logging is Enterprise only	Instances and organizations for B2B tenants; event sourcing keeps every change as an audit trail
Enterprise-only features	Google Workspace and Entra ID integrations, mTLS, privileged access management and password history need Enterprise	Commercial license offered for AGPL-3.0 code; confirm which features sit behind it

What Zitadel's event sourcing changes for audit and operations

Zitadel stores every change as an event, so the history of a role or grant comes from the same record the system runs on. The event store documentation describes this as a built-in audit trail of all changes over an unlimited period. For a regulated team, that answers the question auditors and incident responders ask most often: who changed this role or grant, when, and what did it look like before? Before you rely on that answer, confirm which event types cover the objects your administrators change, and how you query one organization's history within one instance.

authentik lists enhanced audit logging as an Enterprise-only feature on its pricing page, so an authentik deployment that needs audit records should plan for the paid edition from the start. The two products are built differently, and that difference matters for an examiner. Compare what each one records for the events you care about, including role changes, grant changes, provider edits and failed administrative actions. Then compare how long each record is retained in your deployment, and whether it can be exported to your SIEM in a format your analysts can search without custom parsing.

Event history grows with the data. Every change adds events, and self-hosted Zitadel runs on PostgreSQL, so storage, backup and restore times, and query performance all scale with how often administrators and users change things over time, along with the number of identities. Ask your platform team, and the vendor if you buy support, how retention and storage are sized for your expected change rate, whether older events can be archived without breaking the audit window your assessor expects, and who owns database capacity planning. The database configuration guide is the starting point for that sizing. Run a test with representative change volume in a non-production instance, and include the SIEM export in that test.

What AGPL-3.0 and the Enterprise license mean for each

The authentik core is licensed under MIT, so the server, flows, providers and outposts in the main repository can be used, modified and redistributed under permissive terms. Code in the authentik/enterprise directory sits under a separate enterprise license, and production use of that code requires a paid subscription. The pricing page lists three editions, and the figures below are the ones published there.

Open Source: free, with community support available through Discord only.
Enterprise: $5 per user per month billed annually, plus $0.02 per external user per month. Internal user count drives most of this cost, so ask how external users are counted in your scenario.
Enterprise Plus: starts at $20k annually and adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements.
Enterprise-only features: Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. Ticket-based support applies to subscriptions over $1k.

Confirm which enterprise features your use case needs, and check with authentik that your subscription and user counts match the current pricing page before you budget.

What drives the running cost of each identity provider

Running either platform costs more than the license line on a quote. Infrastructure, skills, subscriptions, upgrade work and the external user population each move the total, and they recur on different schedules. Use these cards to build the list of questions to put to each vendor before comparing totals.

Infrastructure and database footprint

authentik's Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. Both platforms store state in PostgreSQL, and Zitadel supports PostgreSQL 14 to 18 for self-hosting, so the database is a shared line item to size, back up and make highly available. Ask each vendor what high availability topology it expects for your load, and whether the database is yours to operate or a managed service you pay for separately.

Operator skills and build effort

authentik's flows, stages and outposts are configured mostly through its admin interface and extended in Python, which suits teams already fluent in that stack. Zitadel is a Go service built on an event model, where every change is stored as an event. Plan for the skills each product demands: an event-sourced store changes how you reason about data, backups and migrations. Ask who on your team will own flow design, custom code and incident response, and whether that staff time is in the quote.

Enterprise subscription fees

authentik's enterprise code sits under a separate license and needs a paid subscription for production use, and its pricing page lists per-user fees for Enterprise plus a per-user charge for external users. Zitadel's enterprise terms are not published as a price list, so request a written quote for its commercial license. Ask both vendors which features your use case needs, because Entra ID and Google Workspace integrations, mTLS and audit logging are gated behind the paid tier on the authentik side.

Upgrade cadence and patch windows

authentik names releases by year and month, and its security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes, with security releases announced at least 24 hours in advance. Zitadel's current release is v4.19.5. Each upgrade consumes internal test time, and a faster cadence means more frequent regression testing. Ask each vendor for its supported version policy and the notice it gives before a security release, and agree who runs staging tests and rollback drills.

External user population

Customer-facing use means many external identities, and cost follows that count on both sides. authentik charges per external user on its published Enterprise pricing, while Zitadel's multi-organization model lets each customer organization bring its own identity provider, which changes how much administration you carry. Model the external user count at peak and at growth, and ask Zitadel whether its commercial terms price by organization, instance or user.

Moving between authentik and Zitadel later

This sequence moves identity from one platform to the other without losing track of applications, users or the audit trail. It ends with one live system, a documented cutover and an archived record of the old platform.

Inventory applications and protocols in use
List every relying application and record how it signs users in: OpenID Connect, OAuth 2.0, SAML, LDAP bind, RADIUS, or a proxy route in front of an application that has no native sign-in. Note the redirect URIs, client secrets, token lifetimes and any claims or attributes each application reads. Owners of each application confirm the list. Done when every application has a named owner and a protocol recorded, and the list is agreed before any tenant or instance is built.
Export users, groups and credentials
Pull user profiles, group memberships and external identity links from the source platform, and decide what transfers. Profile data and group membership usually move through an export or the APIs of each platform. Passwords and MFA enrollments are the hard part: most teams plan for users to re-enroll passkeys or second factors, but a password hash migration or just-in-time approach may be possible in your setup. Confirm the options with the vendor and your security team before promising users anything. Done when a record count per source reconciles with the import and each credential decision is written down.
Map roles and grants to the target model
Translate the source authorization model into the target. In Zitadel, applications sit inside projects, with roles and grants that determine who can use what, and organizations hold users inside an instance. In authentik, access is typically shaped by groups, policies and bindings to applications and providers. Write a mapping table from each source role to its destination, flag any role that does not map cleanly, and have application owners sign off. Done when every application has a tested set of roles with one reviewed mapping for each.
Rebuild providers, outposts and proxy routes
Recreate each client, provider and proxy route on the target platform, including authentik outposts for proxied applications or Zitadel application registrations for OIDC and SAML clients. Point each application at the new issuer or metadata and test login, logout, token refresh and any LDAP or RADIUS clients on a staging copy. If you rely on an authentik outpost or a self-hosted Zitadel deployment, confirm the deployment model and network path with your platform team. Done when each application completes a full sign-in and sign-out test on staging with the expected claims.
Run both platforms in parallel during cutover
Keep the source platform live while you move applications in batches, starting with low-risk internal tools and leaving customer-facing applications for later. Route a small group of test users through the new platform, then widen access once support tickets and login failures stay within an agreed threshold you set in advance. Record the rollback step for each batch. Done when every batch has passed its acceptance test and no application still depends on the old platform for sign-in.
Retire the old platform and archive its records
Disable sign-in on the source platform, revoke remaining sessions and client secrets, and remove DNS or proxy entries that still point to it. Before shutting down the database, export audit logs and configuration to storage that meets your retention rules. Zitadel's event store keeps a change history by design, so confirm with your compliance owner how that history and any exported authentik logs will be retained. Done when the source platform has no active clients, the audit export is verified and the decommission is signed off.

Where authentik and Zitadel projects usually run long

The slowest part of an authentik project is usually reconciling identity sources before any application is switched over. If the client needs Entra ID or Google Workspace synchronization, that sits in the Enterprise edition, so the first decision is whether the license is in scope for production, which the authentik Enterprise license terms and the pricing page should confirm for your user counts. Teams then have to map directory attributes to authentik users and groups, decide which source is authoritative for each attribute, and test what happens when an account is disabled upstream. Legacy proxy routes are the other common delay: each application behind an authentik proxy provider needs its own external host, upstream address and policy bindings, and forward-auth rules often have to be rebuilt by hand. Expect the proxy route inventory to take longer than the identity source work. DeployOpen would plan and document this inventory, the mapping rules and the cutover sequence under a fixed scope agreed in writing before work starts. The client still owns which groups may reach which applications and what the access policy says.

On the Zitadel side, the usual delays come from the organization model and from LDAP or OpenLDAP reconciliation. Zitadel lets one instance hold several organizations, and each customer organization can use its own identity provider, so the team must decide who administers each organization, which projects and roles sit inside it, and how B2B users are kept apart from internal staff. Those tenancy choices are hard to reverse once customers have signed in, which is why they belong in a written design before any build work. Passkey enrollment policy is another slow point: Zitadel supports passkeys with password fallback, so the team has to decide whether fallback stays on, how recovery works for users who lose a device, and which user groups must enroll first. Certificate and TLS planning for self-hosted Zitadel, along with the PostgreSQL version and backup approach (PostgreSQL 14 to 18 is supported), should be confirmed against your own environment before cutover. DeployOpen can prepare the runbooks and evidence for these items, while the access policy and tenancy design remain decisions for your security and product owners.

Both platforms share one slow point: aligning audit logging with the SIEM. authentik's enhanced audit logging is an Enterprise feature, and Zitadel's event store records changes as events, so each team needs to confirm which events reach the SIEM, in what format and with what retention, and who reviews them. Outposts on either platform also need certificate and TLS decisions for their endpoints, which affect how long a rollout takes. Ask your vendor and your own security team to confirm these details in writing before the scope is signed. A fixed-scope agreement from DeployOpen would typically cover the logging mapping, outpost certificate plan, runbooks and test evidence, with the access policy, tenancy design and risk acceptance kept as client decisions.

authentik vs Zitadel questions buyers ask before hiring help

Which is cheaper to run, authentik or Zitadel?

Neither platform's license fee settles the question on its own, because the running cost depends on your team, your user model and the edition you need. authentik core is MIT licensed and free to use, but production use of code under authentik/enterprise needs a paid subscription. The authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus from $20k annually. Zitadel's self-hosted core is AGPL-3.0, with a commercial license offered. Running either one means PostgreSQL 14 to 18, hosting, upgrades, backups and monitoring. Ask for a quote built from a written scope that names your user counts, environments and integrations.

Can our team implement authentik or Zitadel without outside help?

A team with strong container, PostgreSQL and identity skills can often run a small pilot alone, but production work usually needs more than one skill set. You will need people who understand OIDC and SAML flows, reverse proxy configuration, directory integration, backup and restore, and upgrade planning. authentik's documentation positions Docker Compose for test setups and small-scale production, so larger deployments need a Kubernetes or hardened host plan. Zitadel recommends a Kubernetes cluster with the official Helm chart for high availability. Decide early which skills you have in-house and which you would hire.

How long does an authentik or Zitadel implementation take?

No general timeline applies, because duration depends on the number of applications, the identity sources you connect, the migration effort from an existing system and how many environments you run. DeployOpen agrees timelines in a written scope before work starts, and most engagements are fixed-scope with scope, deliverables and dates recorded in writing. Ask any provider, including us, to break the plan into integration tasks, testing, cutover and handover so you can see what drives the schedule.

Does the AGPL-3.0 license require us to publish our changes to Zitadel?

AGPL-3.0 obligations depend on how you use and distribute the software, so confirm the interpretation with your legal counsel before deployment. Zitadel relicensed its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, while APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations stay Apache 2.0. Review the LICENSING.md file and the commercial license option with counsel. authentik core is MIT, and its enterprise directory has a separate license, so the obligations differ.

Do we need authentik Enterprise for Entra ID or Google Workspace sync?

Yes, according to the authentik pricing page, which lists Google Workspace and Microsoft Entra ID integrations among the enterprise-only features. If your main need is single sign-on for applications, the free core already covers OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers. If you need to sync users from Entra ID or Google Workspace, budget for the Enterprise subscription and confirm the current terms on the pricing page. Zitadel can federate login with Entra ID and Google, which is a different capability from the directory sync authentik sells as enterprise.

Can Zitadel serve internal workforce LDAP clients?

Zitadel is designed as a multi-tenant identity platform for applications and customer organizations, and its documentation describes LDAP and OpenLDAP as identity providers it can federate with, not as an LDAP directory that your internal clients bind to. If you need legacy workforce clients to authenticate over LDAP or RADIUS, authentik lists LDAP and RADIUS providers. Test any LDAP bind requirement against the current Zitadel documentation in a pilot before you commit.

How do we get a quote from DeployOpen?

DeployOpen does not publish a price list. A quote follows from a written scope, so start by listing the platform, the number of users and applications, the identity sources to connect, the environments, the migration source if any, and the compliance evidence you need. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, so ask for those as separate line items.

Does DeployOpen certify our compliance with these platforms?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those reports. Ask your auditor which evidence they expect for identity controls such as access reviews, MFA enforcement and audit logging, and check that the platform you choose can produce it.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the authentik or Zitadel decision is tested against your real directories, applications and tenancy model before anything is built. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Map which applications need OIDC, SAML, LDAP, RADIUS or proxy protection, and which need a multi-tenant model for customer organizations
Confirm whether Enterprise-only integrations such as Entra ID or Google Workspace sync are needed before the edition is chosen
Agree in writing whether the AGPL-3.0 terms of Zitadel and the enterprise license terms of authentik fit your distribution and hosting model

How we build

Deploy authentik or Zitadel in your cloud account, data center or air-gapped network, with PostgreSQL in the supported version range
Configure identity sources, flows, providers and organizations or instances, then integrate the applications that will sign in through them
Test login, provisioning, failover and audit log output against the scope, and record the results for your review

How we hand over

Deliver architecture notes, configuration records, runbooks for upgrades and backups, and the list of open items for your team
Document the exit path, including how users, groups and provider settings would be exported if you later move to another platform
Walk your administrators through daily operations, and record what is owned by your staff and what is owned by DeployOpen

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the original implementation
Plan upgrades against the vendor release lines and security policies you confirm, so patch timing is agreed in advance
Re-run security testing after major changes to identity flows, tenancy structure or the number of connected applications

authentik vs Zitadel