authentik or Zitadel: which identity provider fits your shortlist
Choose authentik when the main job is securing staff access to internal applications, and choose Zitadel when the identity layer is part of a product that serves many customer organizations, each managing its own users. authentik's core is MIT licensed and covers OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, which suits a workforce with a mix of modern and legacy apps. Zitadel is built around organizations, which map closely to tenants in a SaaS system, and it is licensed under AGPL-3.0-only with a commercial license available, so its license terms carry more weight when identity is embedded in a product you distribute.
authentik fits an IT team that wants to put a web login portal in front of internal tools, reach older applications through LDAP or RADIUS, and run a single PostgreSQL-backed deployment with an embedded outpost. Zitadel fits a product team that needs each customer to have its own isolated organization with its own administrators, and that values an event-sourced audit trail of every change over an unlimited period. Both are newer than Keycloak, so the comparison should rest on your own tests rather than on general reputation.
The decision turns on four questions. Who the users are: employees, partner staff or end customers. Whether tenants must be isolated inside one instance. Which protocols your legacy apps need, since LDAP, RADIUS and SAML requirements can settle the choice early. And how you will license and support the platform, because code under authentik/enterprise needs a paid subscription for production use, and Zitadel's AGPL terms apply to the product you ship. Confirm the edition-specific features and support terms with each vendor in writing before you shortlist, and ask DeployOpen to map those answers to your environment.
Which platform fits which scenario
This table maps five common scenarios to the platform that fits each one better, with the reason and the condition under which the other platform would win. Read each row against your own user base, application mix and Kubernetes capacity, since the fit shifts with those factors more than with feature lists.
| Scenario | Better fit | Reason and condition for the other platform |
|---|---|---|
| Internal workforce SSO for employees and staff apps | authentik | authentik's OAuth2/OIDC and SAML providers and its proxy outposts cover internal web apps with one administrative model. Zitadel would win if the organization needs its multi-organization model for partner or subsidiary admins. |
| Legacy apps that need LDAP or RADIUS | authentik | authentik lists LDAP and RADIUS among its provider types, so legacy systems can authenticate without a custom bridge. Confirm the exact LDAP and RADIUS behavior each legacy app needs, since Zitadel's protocol coverage should be checked against that list before you decide. |
| B2B SaaS where each customer admins its own users | Zitadel | Zitadel's organizations map to tenants, and multiple organizations sit in one instance, which suits customers managing their own users. authentik would be a reasonable choice if you only need a small number of administrative boundaries and prefer its proxy model. |
| Customer-facing login with branding per tenant | Zitadel | The organization model gives each tenant its own identity boundary, which is the structure branded logins usually depend on. Confirm the branding options for each tenant in the current Zitadel documentation before you commit to a per-tenant design. |
| Team with limited Kubernetes skills | authentik | authentik runs as a server container with an embedded outpost plus a worker, backed by PostgreSQL, which is a smaller operational footprint to start with. Zitadel can also run self-hosted, so the decision depends on how much cluster operations your team can absorb. |
How authentik and Zitadel are built and what that means for operations
authentik and Zitadel make different architectural bets, and those bets shape how you upgrade, back up, scale and troubleshoot each platform. The four components below are where a proof of concept should spend most of its time, because each one changes who owns which failure mode.
authentik server, outpost and worker
authentik runs as a server container with an embedded outpost, plus a separate worker container. The embedded outpost handles proxy and LDAP or RADIUS traffic for internal applications, so network placement and scaling of that path follow the server container. Upgrades touch both containers, so confirm the version pairing and rollout order in your deployment tooling. In a proof of concept, test a failed worker and a restarted server and check which sign-in and background tasks stop.
authentik configuration in PostgreSQL
authentik stores its configuration and data in PostgreSQL, which makes the database the system of record for users, flows, providers and applications. Backups therefore need to capture the database consistently with any media or secrets your deployment references outside it. Restore testing matters more than backup frequency, because a restored database must bring back working providers. Confirm how your team will rehearse a point-in-time restore and how long the database is unavailable during a major version upgrade.
Zitadel event-sourced store
Zitadel is built on event sourcing, storing every change as an event. This gives a built-in audit trail of all changes over an unlimited period, which helps when an auditor or incident responder asks who changed a role or client. The same design means the event history grows with activity, so plan storage and retention with the vendor documentation in hand. Ask for a worked example of how Zitadel projections rebuild after a database incident and how long that takes at your data volume.
Zitadel database support and operations
Self-hosted Zitadel supports PostgreSQL 14 to 18, so your existing database standard must match that range before you commit. Check that your managed PostgreSQL service offers those versions, since a platform team may be on a different major release. Upgrading the database and Zitadel together is a planned change, not a routine patch. Confirm the supported upgrade path for your current Zitadel release and the PostgreSQL version you run, and test it against a copy of production data.
Zitadel organizations inside one instance
In Zitadel, an organization works like a tenant in a SaaS system, and several organizations can live in one instance. This suits B2B products whose customers manage their own users, but it also means one instance carries every tenant's configuration, so a bad change or an outage can reach many customers at once. Test how you delegate administration between organizations, how you isolate scaling and rate limits for a noisy tenant, and how support staff troubleshoot one organization without touching another.
Protocols, databases and tenancy compared side by side
This table compares protocol coverage, database support, tenancy model, audit design and license terms for authentik and Zitadel, using the release lines current at the time of writing. Read it as a checklist: where a row says to confirm, the supplied research does not settle the point, so verify it with the vendor before you decide.
| Capability | authentik | Zitadel |
|---|---|---|
| Current release line | 2026.8.4 (released October 14, 2026) | v4.19.5 (released October 15, 2026) |
| OAuth 2.0 and OpenID Connect | Provided through its OAuth2 and OpenID Connect provider | Supported as a core identity provider function; confirm the exact flows you need with the vendor |
| SAML | Provided through its SAML provider | Confirm SAML support and version coverage with the vendor |
| LDAP | Provided as an LDAP provider, typically served through an outpost for internal applications | Confirm LDAP availability in your target edition with the vendor |
| RADIUS and proxy access | Provides RADIUS and proxy providers, suited to network devices and internal web apps | Not covered by the supplied research; confirm with the vendor before assuming a match |
| Database for self-hosting | PostgreSQL stores configuration and data | PostgreSQL 14 to 18 supported for self-hosted deployments |
| Tenancy model | Built around applications, providers and users within a single installation; confirm multi-tenant options with the vendor | Organizations act like tenants in a SaaS system, with many organizations inside one instance for B2B products whose customers manage their own users |
| Audit trail | Confirm the audit log retention and export options with the vendor | Event sourcing stores every change as an event, giving a built-in audit trail of all changes over an unlimited period |
| License | MIT core; code under the enterprise directory needs a paid subscription for production use | AGPL-3.0-only from v3 (April 2025), with some client packages under Apache-2.0 or MIT and a commercial license offered |
What each license allows and what the paid edition covers
The authentik core is licensed under the MIT license, which permits use, modification and redistribution with few conditions. The exception is code under authentik/enterprise, which the project places under the authentik Enterprise Edition license. That code needs a paid subscription for production use, so the license split follows the directory tree rather than the feature names you see in the product. Confirm where each feature you need lives before you assume it is free.
- Core license: code outside
authentik/enterpriseis MIT licensed, so the license itself imposes no subscription for running the core. - Enterprise tree: code under
authentik/enterpriserequires a paid subscription for production use. Check whether your planned features sit there. - Provider scope: the documented providers include OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy. Ask the vendor which of these you need are in the core and which are in the enterprise tree.
- Recurring cost: the subscription recurs for as long as you run enterprise code in production. The license file gives no price, so request one in writing.
Check the file paths of every feature in your design against the authentik LICENSE file before you commit to an architecture.
Zitadel was licensed under Apache-2.0 before v3. With Zitadel v3, the project moved to AGPL-3.0-only in April 2025. The project's LICENSING.md states that some directories, such as client packages, remain under Apache-2.0 or MIT, and that a commercial license is offered. A team selecting Zitadel today is adopting AGPL for the server code, so the directories it actually uses determine which terms apply.
- Relicense date: the move to AGPL-3.0-only happened in April 2025 with Zitadel v3. Earlier releases carry Apache-2.0 terms, so the version you deploy matters.
- Server license: the server code is AGPL-3.0-only, which is the license that carries the network-use obligations discussed in the next tab.
- Permissive directories: some directories stay under Apache-2.0 or MIT. Inventory the packages you use and map each one to its license.
- Commercial license: the project offers one. Ask what it covers, its term and whether it changes the obligations you would otherwise carry under AGPL.
Map your build and deployment against the Zitadel LICENSING.md and confirm the license of each directory you use with the vendor before procurement.
AGPL obligations matter most when identity runs inside a product that other people use over a network. Under AGPL, a team that modifies the server and lets users interact with that modified version over a network generally has to offer those users the corresponding source of the modified version. Internal use inside one organization raises different questions than a customer-facing service. Whether a given deployment triggers those duties depends on the license text and on how the product is delivered, so have counsel review the plan.
- Unmodified use: running an unmodified server carries lighter source obligations than running a modified build, but confirm this reading with counsel.
- Network interaction: AGPL's network clause is the reason customer-facing hosting needs review, because customers interact with the service over a network.
- Modifications: custom changes to the server, such as a patched login flow, are the changes most likely to carry source obligations.
- Permissive alternative: authentik's MIT core is permissive, but its enterprise tree has its own license, so the comparison depends on which code you embed.
Settle the license path before design starts, because moving later usually means re-architecting around different terms or buying a commercial license.
The supplied facts for this comparison do not list which features sit in either vendor's paid edition, so the feature split must come from each vendor in writing. Ask for a feature-by-feature table that names the edition for each capability and the release in which it became available. Both projects change between releases, so a table tied to a version is more useful than a marketing summary. Bring your intended deployment shape, application count and support needs to the request so the quote matches the scope.
- Feature table: request each capability, the edition that includes it and the release that introduced it.
- Production definition: ask what production use means in the subscription terms, including whether test and staging environments are covered.
- Term and exit: ask for the term, renewal conditions and what you may keep running if the subscription lapses.
- Patch coverage: confirm which release lines receive fixes. authentik's 2026.5 and 2026.2 lines still received patches on September 9, 2026, so ask how long each line is supported.
Store the written answers with your scope document, so the comparison, the quote and the license terms stay consistent with one another.
Identity integration: directories, legacy apps and extensibility
The first question for either platform is which parts of your estate must authenticate against it and how. authentik is built around the idea that an identity provider also sits in front of applications that cannot speak modern protocols. Its provider set includes OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, and its architecture runs an embedded outpost alongside the server and a worker container, with configuration and data held in PostgreSQL. For internal applications that expect a directory bind, a RADIUS exchange or a login in front of a web app with no native SSO, that breadth is the reason to shortlist it. Confirm in the authentik providers documentation exactly which LDAP attributes, group mappings and RADIUS features your application needs, and whether a proxy outpost can run in the network segment where those applications live.
Zitadel approaches identity from the other direction. Its organization model treats each organization as a tenant within one instance, which suits a B2B product where each customer's administrators manage their own users, roles and login policies. The integration questions shift accordingly: whether your customers need to bring their own upstream identity provider, whether their directory admins must be isolated from one another, and whether your product needs custom claims in tokens that differ per organization. Before deciding, check how Zitadel's documentation handles upstream identity provider configuration, claim mapping and action or hook extension points for your version, and whether LDAP or RADIUS-style legacy access is offered at all. If it is not, legacy applications must be bridged by other means, and that cost belongs in the comparison.
Both platforms need the same due diligence on provisioning and extensibility. Ask who creates accounts when a user joins, whether that happens through SCIM, an upstream directory sync or an API call, and what happens to access when an account is removed. Map every custom claim your applications consume and record where each one is set. Then have your team test the two most important flows end to end in a non-production environment: the legacy application login and the customer-administered onboarding path. Those tests will show gaps that feature lists do not, and they give your procurement and security reviewers evidence that a quote can be scoped against.
What drives the running cost of each platform
Running cost for authentik and Zitadel is set less by licence fees than by the infrastructure, people and support work around them. Each card below names who gets paid, what is one-time and what recurs, and what to ask for in a written quote before you commit.
PostgreSQL and container infrastructure
authentik runs a server container with an embedded outpost plus a worker container, and stores its configuration and data in PostgreSQL. Zitadel supports self-hosted PostgreSQL 14 to 18. In both cases your cloud or data center bill carries the database instance, storage, backups and compute for the application containers, and this cost recurs every month. Ask the quote to separate database hosting from application hosting, and to state whether high availability and replicas are included or priced as extras.
Staff skills for PostgreSQL and containers
Someone on your team must operate PostgreSQL and the container runtime, including upgrades, failover and restores. This is an internal payroll cost that recurs, and it is often larger than infrastructure spend. Check which of your engineers already run PostgreSQL in production and which container platform you use. If the skills are missing, a quote for implementation work can include knowledge transfer, but the ongoing operating hours stay with you.
Enterprise Edition and commercial licence needs
authentik core is MIT licensed, but code under authentik/enterprise needs a paid subscription for production use. Zitadel was relicensed to AGPL-3.0-only with v3, and a commercial license is offered. Either way, the fee is recurring and is paid to the vendor, not to DeployOpen. Confirm which features you need sit in the paid code, whether the AGPL obligations fit your product distribution, and get the subscription price and renewal terms in writing from each vendor.
Upgrades and patches across release lines
authentik publishes a current release line alongside older lines that still receive patches, and Zitadel ships its own major and minor cadence. Each upgrade needs a test environment, a database migration rehearsal and a rollback plan. This effort recurs for the life of the system. Ask whether the quote covers one upgrade per year, per release, or on demand, and who signs off the change window.
Backup, audit and log retention
Zitadel stores every change as an event, which gives a built-in audit trail over an unlimited period, so its event store grows with use and must be backed up and retained under your policy. authentik requires backups of its PostgreSQL data, and log retention is set by your own tooling. Storage for these records recurs. Ask the quote how backup testing, restore drills and retention periods are scoped, and confirm the retention period you need with your compliance lead.
Support retainer after go-live
Most DeployOpen 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, which recur. A retainer is separate from the vendor subscription. Ask for the scope of covered incidents, response expectations in writing, and whether patch application and security testing are included. DeployOpen does not publish a price list, so the quote follows from the written scope.
Moving from authentik to Zitadel or back: what transfers and what is rebuilt
This sequence turns a platform switch into a reversible, application-by-application project, so each cutover can be tested, measured and rolled back before the old instance is retired.
Inventory applications and protocols
The platform owner lists every application that signs in through authentik, with its protocol (OAuth2/OpenID Connect, SAML, LDAP, RADIUS or a proxy provider), its owner, its redirect URIs, its token lifetimes and any downstream systems that depend on its claims. Proxy-protected internal apps and LDAP or RADIUS clients often have no written record, so they need a check against live configuration and network traffic. The step is done when every application has one row in a shared register and the owner has signed off on it.
Map users, groups and attributes
The identity team exports users, groups, group memberships and custom attributes from authentik and maps each one to its Zitadel equivalent. Passwords and MFA enrollments generally do not move as stored secrets, so the team should decide in advance whether users re-enroll, whether a password reset flow is used, or whether an approved import method is available for the specific data. Confirm the exact import options with Zitadel for your version. The step is done when a mapping document covers every user attribute that an application reads.
Decide the tenant structure
Zitadel models customers as organizations within one instance, while authentik typically serves a single directory with groups and policies. The architect decides whether internal users stay in one organization, whether each customer or business unit gets its own organization, and how administrators are delegated. This choice drives how users and roles are created during the rebuild, so it must be settled before any client is registered. The step is done when a written tenant diagram is approved and the admin roles per organization are listed.
Rebuild client registrations and claims
Each application gets a new client registration in Zitadel with the same redirect URIs, scopes and signing settings as the authentik original. Claims, role mappings and any authentik property mappings are rewritten by hand, because policy logic and expressions do not translate automatically. Test every claim the application reads, including group or role claims that drive authorization. The step is done when each application completes a sign-in in a non-production environment and the token claims match the register from the first step.
Run both platforms for a test group
A small group of named users signs in to migrated applications on Zitadel while everyone else stays on authentik. The team monitors failed logins, claim errors, session behavior and support tickets, and compares audit records from both systems. Both instances must stay synchronized for the users in the test group, so the team needs a documented rule for where a password change or a group change is made during this phase. The step is done when the test group has used each migrated application through its normal workflow without a blocking issue.
Cut over application by application
Each application moves on its own schedule, starting with the lowest-risk one. The team changes the application's identity settings to point at Zitadel, keeps the authentik client registration disabled but not deleted, and records the exact time and configuration change. A rollback plan for each application names the setting to revert and the person who approves the revert. The step is done when every application has a signed cutover record and its rollback path has been tested once.
Retire the old instance
Once every application has run on the new platform through an agreed observation period, the team exports a final copy of authentik configuration and data, stores it under the retention rules that apply to the organization, and removes the authentik outposts and worker containers. Anything the organization is required to keep for audit or incident review is kept in readable form, not only as a running system. The step is done when access to authentik is removed, the final export is verified, and the register is marked closed.
What implementing each platform involves and where projects run long
Implementing authentik starts with PostgreSQL, because authentik stores its configuration and data there. The usual deployment runs the server container, which includes an embedded outpost, alongside a separate worker container. Teams then configure each application against the provider type that fits it: OAuth2 and OpenID Connect, SAML, LDAP, RADIUS or a proxy provider. Proxy and LDAP outposts for internal applications need network placement close to those applications, so plan that layout before onboarding begins. Hardening work includes securing the database, separating server and worker roles, and deciding how outposts authenticate to the core. Confirm the exact container and Kubernetes layout with the current authentik documentation for your target release, since it changes across releases.
Implementing Zitadel starts with a self-hosted PostgreSQL database, where the supported range is PostgreSQL 14 to 18. The larger design decision comes before any container is deployed: how organizations map to your customers. Because each organization carries its own users and administrators, the choice affects onboarding, branding, delegated administration and how customer administrators are trained. Application onboarding for customer-facing products then follows the organization model, and hardening focuses on the instance, the database and the administrative console. Zitadel's event-sourced store records changes as events, which helps later audit questions. Plan how that history is retained, queried and exported before the first auditor asks for it.
Projects with either platform usually run long in four places. Legacy application integrations often need behavior that standard OpenID Connect or SAML configuration does not cover, such as LDAP binds, header-based sign-in or nonstandard claim mapping. Tenant model decisions made late force rework of onboarding flows and permissions. Paid feature gaps appear late when a team assumes a capability is included. For authentik, code under authentik/enterprise needs a paid subscription for production use, so check each required feature against that boundary. For Zitadel, confirm in writing which capabilities fall under its commercial license. Audit and compliance evidence collection is the last risk. DeployOpen prepares controls and evidence, but independent auditors issue any reports, so agree on the evidence set in the written scope at the start.
How much does it cost and how long does an authentik or Zitadel project take
What drives the cost of an authentik or Zitadel implementation?
The cost follows the written scope more than the product license, because both authentik's core and Zitadel's open-source edition can be deployed without a license fee. The main cost components are the number of applications to connect (OIDC, SAML, LDAP, RADIUS or proxy providers for authentik; OIDC and SAML applications and organizations for Zitadel), the directories or upstream identity sources to federate, the number of environments, the hosting and database setup inside your infrastructure, and the work on branding, flows, hardening, backup and documentation. Ask any quote to itemize these, to state which items are one-time and which recur, and to name who pays for what, including any paid subscription separately.
How long does a typical authentik or Zitadel project take?
No duration is fixed by the product itself, so the timeline depends on scope, and DeployOpen agrees timelines in writing before work starts. The factors that lengthen a project are the count of integrated applications, legacy systems that need LDAP or RADIUS bridging, custom authentication flows, multi-tenant organization design for Zitadel, and the number of approval rounds from your security and compliance teams. Ask for a milestone plan that separates design, build, integration testing, cutover and handover, and confirm which dependencies (access to directories, DNS, certificates, database hosts) sit with your staff.
Can our team run authentik or Zitadel without an outside partner?
Yes, a capable platform team can deploy and operate either product, and both publish self-hosting documentation. Teams that do it alone usually need in-house skills in PostgreSQL administration, container or Kubernetes operations, certificate management, and identity protocols such as OpenID Connect and SAML. The question to answer honestly is who will patch, back up, upgrade and test the system on a schedule, because those tasks recur for as long as the product runs. A partner engagement can cover some or all of those tasks through a fixed-scope project or a retainer, and the split should be written down.
What does the work require from our own staff?
Expect your staff to supply access, decisions and review, not just approvals. Typical requirements include named owners for each application being connected, someone who can grant access to your existing directories or identity sources, a database and hosting environment that meets your standards, and reviewers for security configuration, logging and backup restore tests. Ask the quote to list each staff role, the expected involvement per role, and the handover material you will receive, such as runbooks and configuration records.
Does authentik or Zitadel require a paid vendor subscription for production use?
The answer differs by product. authentik's core is MIT licensed, but code under the authentik/enterprise directory is under the authentik Enterprise Edition license and needs a paid subscription for production use, so you must confirm which features your design depends on. Zitadel was relicensed to AGPL-3.0-only with Zitadel v3 in April 2025, and the project offers a commercial license, so organizations that embed Zitadel in a product or do not want AGPL obligations should review that option with the vendor. Confirm your edition and license obligations with the vendor and legal counsel before the design is fixed, since a subscription is a recurring cost separate from any implementation quote.
How do we switch to the other product later if the first choice does not fit?
Switching is possible but costs real effort, and the cost rises with the number of applications, custom flows and stored user data. Both products keep users, applications and configuration in PostgreSQL-backed storage, but the object models differ, so a move usually means re-creating providers or applications, migrating or re-linking users, and re-testing every sign-in path. Keep your application integrations on standard protocols where possible, document custom logic outside the identity product, and ask any implementation quote to include a migration exit plan and the data export steps.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik vs Zitadel, we start by agreeing on which identity model your products and internal applications actually need, then write the scope before any work begins.
How we scope
- We map which applications need OIDC, SAML, LDAP, RADIUS or forward-auth proxy protection before choosing a platform.
- We confirm whether customers will manage their own users, which determines whether organization-based tenancy matters for you.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We deploy the chosen platform into your environment with PostgreSQL configured for production, not a development database.
- We integrate sign-in with your applications, directories and any upstream identity sources, then test login, logout and failure paths.
- We review the licensing position for each component, including which features depend on a paid enterprise subscription, and flag those for your decision.
How we hand over
- You receive architecture, configuration and runbook documentation covering the deployed identity components and their dependencies.
- We document backup, restore and upgrade procedures so your team can operate the platform without us for routine tasks.
- Compliance evidence is prepared for your auditors, who issue any assessment result, since DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can plan upgrades across the release lines each vendor publishes, confirming compatibility before any change in production.
- Security testing of the identity layer, including applications and APIs, can be scoped as a separate engagement against your environment.
