Auth0 vs ZITADEL: when each option fits
A managed Auth0 tenant fits best when your team wants login handled as a service, has no appetite for running a stateful identity system, and can accept MAU-based pricing as a predictable operating cost. ZITADEL fits best when a renewal, a rising monthly active user bill, a data residency requirement or B2B tenant isolation pushes you to keep identity data in your own infrastructure and you have the operating capacity to run it. The decision turns on four things: the tenancy model you need, where customer identity data must live, the team who will operate the platform, and how hard it will be to move existing users and password hashes.
Start with tenancy. ZITADEL's instances give full data isolation, and organizations inside an instance hold users and projects, so compare that structure with how your Auth0 Organizations and tenants map to customers today. Then check data location. If an EU or sector regulator requires identity records and logs to stay in a specific facility, a self-hosted deployment answers that directly, while a managed tenant depends on the vendor's regional options. Confirm both points with Auth0's current documentation and your own legal team rather than assuming either answer.
Operating capacity and migration are the constraints teams most often underestimate. A self-hosted ZITADEL instance needs PostgreSQL (versions 14 through 18 are supported), upgrades, backups and high availability planning, and the official Helm chart is the documented route for a highly available Kubernetes deployment. On the migration side, Auth0 includes password hashes only through a support request on paid plans, so ask Auth0 early what it will deliver and when, before you commit to a cutover date. Also check the AGPL-3.0 license that ZITADEL uses for its core, since your legal team may need to review it against how you plan to modify and offer the service.
Which platform fits which scenario
This table maps common Auth0 buying situations to the platform that usually fits best, with the reason tied to ZITADEL's structure, self-hosting options and Auth0's monthly active user pricing. Use it to find your closest scenario, then confirm the open items in your own environment before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Small consumer app with no dedicated operations team | Auth0 (usually) | Running ZITADEL means operating PostgreSQL 14 or later, upgrades and high availability, which a small team may not have. Confirm the current Auth0 plan limits for your user count. |
| B2B SaaS where each customer brings its own identity provider | ZITADEL | Organizations inside an instance hold users and projects, and each customer organization can use a different identity provider, including OIDC, SAML and LDAP. |
| EU data residency mandate with data kept in your own datacenter | ZITADEL (self-hosted) | Self-hosting lets you choose where user records, logs and database backups live. Confirm the hosting location and support access model with your legal team. |
| Team with existing Kubernetes operations | ZITADEL (self-hosted) | ZITADEL supports Kubernetes with the official Helm chart and recommends it for high availability, so existing cluster tooling and monitoring can be reused. |
| Regulated buyer requiring full control of identity data and audit trails | ZITADEL (self-hosted) | Self-hosting keeps the database, configuration and access logs under your control. Your assessor will still expect evidence of backup, access review and change control. |
| Multi-tenant platform needing strict isolation between customers | ZITADEL (self-hosted) | Instances give virtual tenants with full data isolation, while organizations and projects separate roles and grants inside each instance. |
| Organization with a predictable, high MAU forecast and a budget for managed services | Depends on cost model | Auth0 bills by monthly active users, while self-hosted ZITADEL shifts cost to infrastructure and staff. Compare both using a written scope and a quote. |
| Team that needs a supported, hosted service with vendor-managed upgrades | Auth0 (usually) | Auth0 operates the service for you. With self-hosting, your team or a partner owns patching, upgrades and incident response. |
How Auth0 Organizations and ZITADEL instances model tenants
Tenant modeling is the first decision to get right when moving B2B customer identity from Auth0 to ZITADEL, because ZITADEL does not map one-to-one onto Auth0's tenant and Organizations concepts. In ZITADEL, an instance is a virtual tenant with full data isolation, organizations sit inside an instance and hold the users and projects, and projects group applications, roles and grants. Auth0 has a tenant, and within it an Organizations feature that gives each customer its own members, roles and login connection. Before you map anything, list which of your Auth0 tenants hold separate customer data and which are really one tenant with many Organizations, since that decides whether you need one ZITADEL instance or several.
Per-customer login is where ZITADEL's model is most specific. ZITADEL can federate login with providers such as Entra ID, Okta, Google, GitHub, LDAP and any OIDC-compliant provider, and each customer organization can use a different identity provider. For a B2B SaaS team, this means each enterprise customer's SSO connection can be configured at the organization level rather than shared across the whole tenant. Confirm in the ZITADEL identity provider documentation which connection settings are per organization and which are per instance, and test one customer's SSO flow end to end before you commit to a layout.
Two points need checking against current Auth0 documentation before you claim parity. First, confirm exactly which Organizations features your plan includes, including member roles, organization-level connections and domain handling, because Auth0 changes these over time. Second, confirm how organization identifiers and custom claims appear in tokens in both systems, since your APIs and authorization code may depend on them. Do not assume a feature on one side has an identical counterpart on the other. Write down each Auth0 Organizations behavior your application relies on, then verify it in a ZITADEL test instance with the same users and applications.
Capabilities side by side: protocols, federation, provisioning and passkeys
This table compares Auth0 and ZITADEL on licensing, protocols, provisioning, passkeys, upstream federation and migration tooling. Where the researched facts do not confirm an Auth0 capability or plan tier, the cell tells you what to confirm with Auth0 before you decide. Use the ZITADEL column as the documented baseline and verify each Auth0 item against your current contract.
| Capability | Auth0 | ZITADEL |
|---|---|---|
| Licensing | Proprietary hosted service; confirm any self-hosted or private deployment options with Auth0 | AGPL-3.0 core, console and hosted login; Apache 2.0 APIs, SDKs, proto files and Helm charts |
| OIDC and OAuth 2.0 | Supported; confirm the grant types and conformance claims you rely on with Auth0 | Implements OpenID Connect and OAuth 2.0 with certified OIDC, per the project repository |
| SAML 2.0 | Confirm SAML support for your application type and which plan tier includes it | Implements SAML 2.0 for applications and upstream federation |
| SCIM 2.0 provisioning | Confirm whether SCIM provisioning is included in your plan and how it is priced | SCIM v2 service provider interface for standardized user provisioning and lifecycle management |
| LDAP and OpenLDAP | Confirm LDAP connector availability and any on-premises agent requirement with Auth0 | Supported as an identity provider for LDAP and OpenLDAP directories |
| Device authorization grant | Confirm device flow support for smart TVs and other input-limited devices with Auth0 | Provides the device authorization grant for devices such as smart TVs |
| Passkeys with password fallback | Confirm passkey and MFA options available on your plan and tenant region | FIDO2 and WebAuthn passkeys, with password login as fallback |
| Upstream identity federation | Social and enterprise connections; confirm the exact providers you need, including Entra ID and Okta | Google, GitHub, GitLab, Apple, Entra ID, Okta, Keycloak, LDAP, JWT and any OIDC provider, chosen per organization |
| Migration guides | Bulk user export through the Dashboard or Management API; password hashes need a support request | Documented migration from Auth0, Keycloak, Firebase and another ZITADEL instance, including just-in-time migration |
Where customer identity data lives and who can access it
Customer identity data holds credentials, profiles and login logs, so where it is stored and who can reach it matters as much as features. The four cards below compare the hosted Auth0 tenant with a self-hosted ZITADEL deployment and the database you would operate beneath it.
Auth0 hosted tenant data location
Auth0 stores users, logs and configuration in a tenant that Okta operates. Ask Auth0 which regions your tenant can use, where backups and logs are kept, and whether a Private Cloud or dedicated deployment changes that. Under the export process, password hashes are not in standard exports, so the paid-plan support request is the only route to them, and Auth0 does not guarantee a delivery date. Plan for that dependency before you commit to a move.
Self-hosted ZITADEL in your environment
With self-hosted ZITADEL, the instance runs in your own cloud account or data center, so you decide the region, network paths and who holds administrative access. ZITADEL structures tenants as instances with full data isolation, organizations and projects. Document which personnel can reach the cluster, the Console and the database, and confirm how the AGPL-3.0 licensing of the core affects any changes you make and distribute.
PostgreSQL database you operate
Self-hosted ZITADEL keeps its data in PostgreSQL, with versions 14 through 18 supported. That database becomes your responsibility: patching, encryption at rest, replication, backup testing and restricted DBA access all sit with your team or your provider. Confirm which PostgreSQL version your platform team will standardize on, and check it against the supported range before installation.
Logs, backups and support access
Identity logs, exports and backups can contain personal data long after a user leaves, and each copy needs an owner. With Auth0, ask how support staff access tenant data and what audit trail you receive. With ZITADEL, you define log shipping, backup retention and deletion procedures. Work through these with counsel and your auditors, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications.
What the AGPL change means for a ZITADEL deployment
ZITADEL changed its license for the core server, Console and hosted login with v3.0 on 31 March 2025, moving them from Apache 2.0 to the GNU Affero General Public License 3.0 (AGPL-3.0). The APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stayed under Apache 2.0. For most teams, that split means the parts you write code against and automate with remain permissively licensed, while the server and login pages carry the AGPL terms. Before you plan a deployment, confirm the current license terms in the project's own announcement and repository, since the split is what your legal team will need to review.
The AGPL matters in a narrower case than many readers assume. Running an unmodified ZITADEL server for your own users, inside your own infrastructure, generally leaves you with no source disclosure duty to outside parties. The obligation becomes relevant when you modify the core, Console or hosted login and let users interact with that modified version over a network, because AGPL extends source availability to those network users. Customizing login pages, branding or flows is where this question tends to arise, so list every change you intend to make to the hosted login and Console before go-live, and record which of them touch the AGPL-covered code rather than the Apache 2.0 APIs and SDKs.
Treat this as a question for counsel, not an engineering decision. Ask your legal team to review the license text, the project's current licensing documentation and your planned customizations, and to confirm whether any Auth0 migration tooling, custom Actions equivalents or internal forks would be affected. Check the current release on the ZITADEL GitHub releases page before you plan, since the latest version noted for this page is v4.19.5, dated 15 October 2026, and newer releases may have changed license or packaging details. Record the version you test against and the version you intend to run in production.
What running ZITADEL in production takes
Self-hosting ZITADEL turns login from a vendor service into four components your team operates: the application, its database, the cluster that keeps it available, and the monitoring that tells you when login is failing. Auth0 handles most of these tasks as part of the subscription, so the comparison comes down to how much of that operating work your own staff can absorb.
Application and upgrades
ZITADEL releases are frequent, and each upgrade changes the running identity service that every application depends on for sign-in. Track the release notes and breaking changes for each version you run, and test upgrades in a non-production instance with a copy of your configuration before rolling them out. Confirm which release line your licensing and support arrangements cover, since the core moved to AGPL-3.0 with v3.0. Ask who on your team owns the upgrade calendar and the rollback plan.
PostgreSQL operations and backups
ZITADEL stores its data in PostgreSQL, and the supported range is versions 14 through 18. Your team owns the database engine, its patching, replication, storage capacity and point-in-time recovery, which Auth0 handles for you. Define a restore test on a schedule, because an untested backup does not prove that users, organizations and signing configuration can be recovered. Decide whether you will use a managed PostgreSQL service in your own cloud account or run it yourself.
High availability on Kubernetes
ZITADEL documents Linux and macOS binaries, Docker Compose and Kubernetes, and recommends a Kubernetes cluster with the official Helm chart for high availability. Login is on the critical path for every application you run, so plan replicas, ingress, certificate renewal, node failure handling and capacity for peak sign-in traffic. Ask your platform team whether the cluster already has the skills and monitoring to run a stateful identity service, and whether a second region or site is required by your recovery targets.
Monitoring and on-call
Someone must be paged when sign-ins fail, token issuance slows or the database runs out of connections, and that alert path must exist before go-live. Define service-level objectives for login, alerts for certificate expiry and database health, and an escalation path that reaches people with production access at any hour. Auth0 carries this operational responsibility for its service, so your on-call rota and runbooks become new recurring costs. Confirm who answers for an identity outage that affects every customer application at once.
Staff time and cost ownership
Self-hosting moves cost from a per-user subscription to recurring infrastructure, database, monitoring and staff time, and the staff time is usually the largest and least visible item. Auth0 removes most of the upgrade, database and availability work from your team, so compare the engineering hours you would reallocate with the hours you would spend on these four components. Ask any implementation partner for a written scope that names the components, responsibilities and handover, and ask your own team what they can sustain.
How a move from Auth0 to ZITADEL is structured
The sequence moves users, tenant structure and login behavior from Auth0 into a self-hosted ZITADEL instance in a controlled order, so that each phase produces evidence the next phase depends on. Tenant configuration and login flows are rebuilt by hand, so the plan should treat them as separate work from the user data.
Inventory the Auth0 tenant configuration
Someone who owns the Auth0 tenant lists every application, API, connection, Organization, role, permission, Action, Rule, branding setting and custom domain. The team records which items carry users, which are used by production applications and which are unused. The output is a configuration inventory that becomes the migration backlog and the acceptance list for the ZITADEL build. Confirm current feature parity for each item against ZITADEL's documentation before deciding it is in scope.
Run the bulk user export
An administrator runs the export users job from the Auth0 Dashboard or through the Management API (POST /jobs/users-exports), choosing NDJSON or CSV output. The output is a complete user file with profile attributes, identities and metadata, which the team checks against the user count in the tenant. Standard exports do not include password hashes, so this file is the input for identity data only. The team stores the export in an encrypted location with restricted access, since it contains personal data.
Request the password hash export
On a paid Auth0 plan, the account owner opens a support ticket asking for the password hash export. Auth0 does not guarantee a delivery date, and the option is not available on the Free tier, so the request should be filed early and tracked as a dependency. If the hashes cannot be obtained, users will need to reset passwords or sign in through another method. The output is the hash file, or a documented decision that users will reset their credentials, and both outcomes are recorded before cutover planning continues.
Map Auth0 Organizations to ZITADEL structure
The architecture team decides how Auth0 tenants and Organizations map to ZITADEL instances, organizations and projects. ZITADEL's instance boundary gives full data isolation, while organizations inside an instance hold projects and users. The mapping document lists each Auth0 Organization, its members, roles, enterprise connection and custom domain, and the ZITADEL object that replaces it. Token claims that applications read are compared before and after the mapping. The output is a signed-off mapping document that the import scripts follow.
Import users and choose a migration method
The team imports users into ZITADEL through its API and tooling, then decides how credentials are handled. If the password hash file was delivered and the hashing scheme is supported, hashes are loaded so users keep their passwords. If not, the team can use just-in-time migration, which ZITADEL documents as an approach, where a user's credentials are checked against Auth0 on first login and then moved. The output is a reconciliation report showing imported counts, skipped records and the credential path used for each user group.
Rebuild Actions and login flows in ZITADEL
Auth0 Actions and Rules, custom login pages, branding and enterprise connections are rewritten as ZITADEL actions, login settings and identity provider configurations. Each Action is reviewed for the claims it adds, the external calls it makes and the data it reads, because these behaviors do not transfer automatically. Applications are switched to standard OIDC settings and tested against the new issuer. The output is a test record covering every application, connection and role, with each rebuilt Action traced back to the inventory item it replaces.
Cut over with parallel running
Before cutover, the team runs ZITADEL alongside Auth0 for selected applications or a pilot group, comparing login success, token contents, MFA enrollment and error rates. DNS, redirect URIs and application configuration are switched in a planned window, and Auth0 stays available for rollback until the team has signed off. Users who did not migrate their credentials complete the agreed path. The output is a signed cutover checklist and a decommissioning plan for the Auth0 tenant, including retention of exported data under the organization's own policy.
Questions buyers ask before choosing ZITADEL over Auth0
How much does it cost to move from Auth0 to self-hosted ZITADEL?
The cost is mostly labor and infrastructure, not a license fee, because ZITADEL's code is free to run under AGPL-3.0 and the Apache 2.0 exceptions. Expect one-time costs for planning, migration, login flow rebuilding and testing. Recurring costs include the servers or Kubernetes cluster, a PostgreSQL database (versions 14 through 18 are supported), backups, monitoring, upgrades and the engineers who operate it. Auth0 costs scale with monthly active users and plan tier, so the comparison depends on your user count and feature needs. Ask any vendor or partner for a quote built from a written scope that lists each component separately.
How long does an Auth0 to ZITADEL migration take?
The duration depends on the drivers you can measure in your own tenant: the number of users, how many applications and SDK integrations must change, how many social and enterprise connections need recreating, and how much of your login logic lives in Auth0 Actions. Migration approaches also matter. ZITADEL documents just-in-time migration, which moves users when they next sign in, and a bulk approach, which moves everyone up front. Each path shifts the testing and cutover work. Ask for a timeline tied to these inputs, not a generic estimate.
Can our team migrate to ZITADEL without outside help?
A capable platform or identity team can run a ZITADEL migration in-house, but it needs skills in OIDC and OAuth 2.0, Linux and containers, PostgreSQL administration, Kubernetes or Docker Compose for hosting, and secure secrets handling. Someone also has to own the rebuilt login flows, the Auth0 Actions logic that must be re-implemented, and the cutover plan. Teams with limited capacity often bring in an implementation partner for a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, but it does not issue audit reports or certifications.
Can password hashes move from Auth0 to ZITADEL?
Standard Auth0 user exports do not include password hashes, so users would otherwise need to reset passwords. Auth0 states that customers on paid plans can request password hash exports through a support ticket, but the option is not available on the Free tier and Auth0 does not guarantee a delivery date. Plan for this request early, because it sits on the critical path. Users who cannot have their hashes moved can be handled with just-in-time migration or a password reset flow. Confirm the hash format and your Auth0 plan with Auth0 before you commit to a cutover date.
Does ZITADEL cover B2B multi-tenant identity needs?
ZITADEL is built for multi-tenant customer identity. It organizes tenants as instances with full data isolation, organizations inside instances where users and projects live, and projects that group applications, roles and grants. Each customer organization can use a different identity provider, such as Entra ID, Okta, Google, SAML or LDAP connections. You should still verify that your Auth0 Organizations model, per-customer domains and member roles map cleanly onto ZITADEL's structure, and test token claims with your applications before migrating. Ask ZITADEL and your implementation partner to walk through a sample tenant built on your own data model.
What does DeployOpen support add to a ZITADEL migration?
DeployOpen support is most useful when you want fixed-scope delivery and a partner accountable for specific outputs. Typical work includes planning the migration, implementing and hardening the ZITADEL deployment in your cloud account or data center, rebuilding login flows, backing up and documenting the system, and preparing controls and evidence for compliance assessments. Ongoing support, upgrades and continuous security testing are available as retainers. Engagements are scoped in writing, and DeployOpen does not publish prices, so you receive a quote that follows from the written scope.
What to confirm with each vendor before deciding
Start by getting Auth0's current terms in writing, because plan limits and add-on conditions drive the cost comparison more than any feature list. Ask Auth0 for the monthly active user tier that matches your forecast, the limits on Organizations and enterprise connections in that tier, and which Enterprise add-ons are required for the features you use, such as SAML connections, custom domains or advanced attack protection. Confirm whether any of those limits change at renewal. Ask for the password hash export conditions in writing as well: the export is available only on paid plans and only through a support request, and Auth0 does not commit to a delivery date. If your migration plan depends on keeping user passwords, make that request early and treat the answer as a schedule input, not a formality. The Auth0 bulk user export documentation explains what the standard export includes and what it leaves out.
On the ZITADEL side, confirm feature availability for the deployment model you intend to run. Self-hosting is documented for binaries, Docker Compose and Kubernetes, and the project recommends the official Helm chart for high availability, but specific features, supported PostgreSQL versions and upgrade paths should be checked against the version you plan to deploy. Because the core moved to AGPL-3.0 with v3.0, ask your legal team to review how that license applies to your use, including whether you modify the software and offer it to users over a network. For support, ask ZITADEL what commercial support, response times and SLA terms are available for self-hosted customers, and what your internal team would own. Ask Auth0 the same questions for its support tiers, and compare the written answers rather than marketing summaries. The ZITADEL pricing page is the starting point for those commercial questions.
Finally, get written answers on data processing locations, sub-processors and support access for both vendors. For Auth0, ask which regions host your tenant, where logs and backups are stored, which sub-processors touch customer identity data, and what support staff can access. For a self-hosted ZITADEL deployment, the processing locations are the ones you choose, but you should still confirm any hosted login, telemetry or support channel that sends data outside your infrastructure. Record each answer with the date and the name of the person who gave it. These records feed your data protection impact assessment and your vendor risk file, and they show auditors that the residency decision was based on evidence.
How DeployOpen helps evaluate and implement ZITADEL
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Auth0 vs ZITADEL, we start by testing whether ZITADEL's tenant model, protocols and login flows fit your customer and B2B requirements before any migration work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map your Auth0 tenants, Organizations, connections, Actions and applications to ZITADEL instances, organizations and projects.
- The written scope states which data location, hosting model and compliance evidence the engagement covers.
How we build
- We deploy ZITADEL on Docker Compose or Kubernetes in your environment, with PostgreSQL in a supported version.
- We configure identity provider connections, SCIM provisioning, passkeys and login customization to match your requirements.
- We test OIDC and SAML flows against your applications and document the results before any cutover.
How we hand over
- You receive architecture, configuration, runbooks and the test evidence produced during the engagement.
- We document how user data, backups and PostgreSQL are handled, so your team can operate the platform.
- We confirm with you which items, such as ZITADEL's license terms or your auditor's requirements, need review by your own legal or compliance team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover ZITADEL version upgrades, backup verification and periodic security testing of login flows.
- Quotes follow from the written scope, so ask for a breakdown of build, handover and retainer effort.
