Clerk vs ZITADEL: when each identity platform fits
Clerk fits product teams that want prebuilt login, sign-up and account screens and no identity infrastructure to run. ZITADEL fits teams that need customer identity data on infrastructure they control and have people who can operate PostgreSQL and either Docker Compose or Kubernetes. Neither is a universal winner. The choice turns on four questions: how much frontend capacity your team has to build and maintain login screens, whether data location rules require identity records to stay in a specific region or datacenter, how often your customers ask for enterprise SSO, and who will be paged when the service misbehaves.
Start with the frontend and the operating model. Clerk's hosted components cover much of the sign-in flow out of the box, so a small team can ship B2B organizations and passkey support without building those screens. ZITADEL gives you a hosted login you run yourself, with its own components and APIs, so your team takes on hosting, upgrades, backups and the database. ZITADEL's core is AGPL-3.0 since v3.0, while its APIs, SDKs and Helm charts remain Apache 2.0. Have your legal team confirm whether that license change affects how you distribute or modify the login components before you commit.
Then test the two requirements that usually decide the matter. For tenant structure, map your customers to ZITADEL's instances, organizations and projects, and confirm that per-customer identity providers and passkey policies behave the way your sales commitments say they will. For SSO, count how many enterprise connections you expect in the next year and ask Clerk for its current per-connection pricing in writing, then compare that with the PostgreSQL, Kubernetes and support hours you would staff for ZITADEL. A short proof of concept with one real B2B tenant will show more than either vendor's documentation.
Which option fits which team situation
This table maps common team situations to the platform that usually fits better, along with the condition that makes each advantage matter. Read each row together with its reason, because most choices depend on details to confirm in Clerk's current documentation and pricing. The main takeaway is that a hosted service suits small teams without identity staff, while self-hosted ZITADEL suits teams that need control over data location, tenant isolation and platform-owned operations.
| Scenario | Better fit | Why |
|---|---|---|
| Small team shipping a web app with no identity staff | Clerk | Clerk removes hosting and identity operations from a small team's backlog. Choose ZITADEL only if self-hosting is a requirement. |
| B2B SaaS team with frequent customer SSO requests | ZITADEL, if connection costs grow | Each customer organization can use its own identity provider. Self-hosting avoids per-connection fees, but confirm Clerk's current enterprise SSO pricing. |
| Team with data residency or contractual control over identity data | ZITADEL, self-hosted | You pick the region and database location for identity data. Ask Clerk to document its storage and processing locations before deciding. |
| Team that wants prebuilt login screens without building UI | Clerk | Clerk's prebuilt components address this need directly. ZITADEL's hosted login is a service you run and configure, so plan front-end time for custom flows. |
| Multi-tenant product needing isolated tenants and per-organization identity providers | ZITADEL | Instances provide full data isolation, and organizations hold projects and users, each with its own identity provider. Confirm that Clerk's organization model fits your tenancy rules. |
| Team with a Kubernetes platform group already running PostgreSQL | ZITADEL | ZITADEL supports PostgreSQL 14 to 18 and recommends the official Helm chart for high availability. Your team then owns backups, upgrades and database capacity. |
Where customer identity data lives and who controls it
Identity data is the most sensitive store in an application, so where it sits and who runs it shapes the migration more than any feature table. The four cards below separate what Clerk hosts for you from what you run yourself with ZITADEL, and what each choice leaves for your compliance team to evidence.
Where Clerk hosts your data
Clerk runs user records, sessions and password hashes as a managed service, so the data location is set by Clerk's hosting arrangements rather than by your infrastructure team. Before you plan a switch, confirm in writing which regions store your production user data, where backups are kept, which sub-processors touch the data, and what your customer agreement says about transfers. Clerk's public materials should be checked against your own contract, not assumed.
Where ZITADEL stores identity data
A self-hosted ZITADEL deployment keeps its identity data in a PostgreSQL database that you provision, secure and back up. ZITADEL supports PostgreSQL 14 through 18, so your database platform team needs to select a supported major version and decide where the instance runs. Every table that holds users, credentials and audit-relevant events lands in infrastructure you operate, which is the core reason regulated teams consider this path.
Hosting options ZITADEL documents
ZITADEL documents three deployment routes: Linux and macOS binaries, Docker Compose, and Kubernetes. For high availability, ZITADEL recommends a Kubernetes cluster deployed with the official Helm chart. Choose the route your platform team can patch, monitor and restore under its own change process, and test the chosen route in a non-production environment before any user data moves. Confirm the Helm chart version and upgrade path against the release you intend to run.
Region, backup and compliance ownership
Under self-hosting, you choose the hosting region, set the backup schedule and retention, and own the restore test. These decisions feed the controls an independent auditor will examine, such as access reviews, change records and backup evidence. DeployOpen prepares those controls and evidence for assessment, but audit reports and certifications come from independent auditors and certification bodies. ZITADEL Cloud is a separate hosted option, so confirm its terms and data location on the ZITADEL pricing page before comparing it with your own deployment.
How Clerk and ZITADEL compare on capabilities
This table compares what Clerk and self-hosted ZITADEL offer across protocols, directory federation, passkeys, B2B tenancy, login screens and migration. Clerk cells name what to confirm in Clerk's current documentation because plan details change, while ZITADEL cells reflect its documented feature set. The main takeaway is that the gaps that matter depend on your login screens, customer SSO volume and migration path, so check each row against your requirements before deciding.
| Capability | Clerk (commercial) | ZITADEL (self-hosted) |
|---|---|---|
| OpenID Connect and OAuth 2.0 | Supported for application login. Confirm which OAuth 2.0 flows and token options your plan includes. | Implements OpenID Connect, OAuth 2.0 and certified OIDC on your own infrastructure. |
| SAML 2.0 and SCIM 2.0 provisioning | Enterprise SSO connections are priced per connection. Confirm SAML and directory sync coverage for your plan. | Supports SAML 2.0 and a SCIM 2.0 service provider interface for user lifecycle management. |
| LDAP directory | Confirm whether LDAP directory connections are offered and on which plan. | Supports LDAP and OpenLDAP as identity providers for existing directories. |
| Federation with Google, GitHub, Entra ID, Okta and Keycloak | Social and enterprise providers are offered. Confirm the current list and any per-connection charges. | Federates with all five over OIDC or SAML, and each customer organization can use a different provider. |
| Passkeys (FIDO2 and WebAuthn) with password fallback | Passkey support is offered. Confirm the fallback and recovery options included in your plan. | Passwordless login with passkeys based on FIDO2 and WebAuthn, with password login as fallback. |
| B2B organizations and tenant isolation | Organizations are a core B2B feature. Confirm how data and policies are scoped per organization. | Instances give full data isolation, organizations hold users, and projects group apps, roles and grants. |
| Prebuilt UI components | Prebuilt sign-in, sign-up and account components reduce the screens your team builds. Confirm theming limits. | Hosted login you run yourself. Confirm theming and customization options in the current documentation. |
| Device authorization grant | Confirm whether device login flows for TVs and command-line tools are supported. | Provides a device authorization grant for devices such as smart TVs. |
| Migration tooling | Confirm the export options and whether password hashes can be exported for your plan. | Documented guides cover Auth0, Keycloak, Firebase and ZITADEL. Confirm whether a Clerk path exists. |
What ZITADEL's AGPL core means for your product
ZITADEL's core is now AGPL-3.0, and that is the first licensing fact to plan around. ZITADEL moved its core, Console and hosted login from Apache 2.0 to the GNU Affero General Public License 3.0 with v3.0 on 31 March 2025. The APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stayed under Apache 2.0, so the integration code your developers write and the deployment tooling you use are still permissively licensed. The obligations that matter sit in the core server and login pages. Read the change in the Zitadel blog post on the move from Apache to AGPL before you write the decision down.
In plain terms, AGPL obligations are most likely to matter when you modify the ZITADEL core and let users interact with that modified version over a network, such as a hosted login you operate for customers. In that case you should expect to make the corresponding source of your changes available to those users under the same license. When you run unmodified ZITADEL inside your own organization for employee or internal application login, the change usually has little practical effect, because you are not distributing the software or offering a modified service to outside users. Ask counsel to confirm which group your deployment falls into, including how a customer-facing login page, custom Console theming or a branded hosted login is classified.
Clerk is a proprietary hosted service, so this comparison is a hosted contract against a self-hosted license. Your Clerk terms govern what you can do with the service, while ZITADEL's license governs what you can do with the code you run and change. Before planning, check the current release on the zitadel/zitadel releases page on GitHub. At the time of writing the latest release is v4.19.5, published 15 October 2026. Pin the version you test against and re-check the license text for that version during your procurement review.
Choosing a ZITADEL deployment model
This option suits a developer or small platform team that wants to evaluate ZITADEL against a proof-of-concept application or test integrations with a single node. ZITADEL documents running its binaries directly on Linux and macOS, which keeps the moving parts few but leaves process supervision, networking and data protection to you. It is a poor fit for production customer login without additional engineering around it.
- Database: You run a single PostgreSQL instance, using a version from 14 through 18, and manage its connections, storage and maintenance yourself.
- TLS: You terminate HTTPS in front of the binary, typically with a reverse proxy, and manage certificate issuance and renewal.
- Backups: You schedule and test PostgreSQL backups and restores, since a single node has no built-in redundancy.
- Upgrades: You plan version changes by hand, including database migrations, and keep a rollback path.
- Monitoring: You add health checks, logs and alerting for the process and the database, because nothing watches them by default.
Before choosing this model, confirm with your security team whether a single node meets your availability and logging expectations, and whether an evaluation environment can hold realistic test identities without exposing personal data.
This option suits a team that wants a repeatable, containerized deployment on one virtual machine or server for a pilot, internal application or a lower-traffic production service. Compose describes ZITADEL and its PostgreSQL database together, which makes the setup easier to version and rebuild. The host remains a single point of failure, so the design depends on how quickly you can restore it.
- Database: You run PostgreSQL in a container or on a managed host, on a supported version from 14 through 18, with persistent volumes that survive container replacement.
- TLS: You place a reverse proxy in front of the stack and keep certificates and private keys out of the Compose file.
- Backups: You back up the database volume and configuration files to a separate location and test restores on another host.
- Upgrades: You pin image tags, read release notes before each change and rehearse database upgrades in a staging copy.
- Monitoring: You collect container health, disk space and database metrics, and alert on certificate expiry.
Confirm that one host meets your recovery time objective, that your team can rebuild it from backups within your change window, and that your data classification allows this placement.
This option suits platform engineering teams that already run Kubernetes and need high availability, rolling upgrades and standard cluster tooling. ZITADEL recommends the official Helm chart for high availability, so this is the path most closely aligned with the vendor's guidance for production. It also brings the highest operating load, because the team owns the cluster, the ingress and the database.
- Database: You provision a highly available PostgreSQL service, using a version from 14 through 18, with replication, failover and connection limits sized for the workload.
- TLS: You manage certificates through ingress controllers or a certificate manager, including rotation across replicas.
- Backups: You run database backups with point-in-time recovery and rehearse cluster rebuilds, not only data restores.
- Upgrades: You upgrade the chart and the database in a planned sequence, reviewing chart values and migrations before each change.
- Monitoring: You adopt cluster and application observability, covering pod health, latency, login error rates and database saturation.
Confirm that your cluster and database platform are already supported by your operations team, that you have an on-call rotation for identity services, and that the chart values you use match your own network and security policies.
This option is a hosted alternative rather than a self-hosted deployment. It suits teams that want ZITADEL's features without operating the database, upgrades or availability themselves, but it moves data and operations to a third party. Because the hosting arrangement changes where identity data resides and who controls it, treat it as a separate decision from the self-hosted options.
- Data location: Ask where tenant data is stored and processed, and whether a region matching your residency requirement is available.
- Responsibility: Ask which security, backup, patching and incident duties the provider keeps, and which remain with you.
- Terms: Read the service terms and the license implications of hosted use before you commit, since ZITADEL's core is AGPL-licensed.
- Exit path: Confirm how you export users, password data and configuration if you later move to self-hosting.
- Pricing: Request the current pricing and any usage limits in writing from the provider, as they can change.
Confirm all of these points directly with ZITADEL against the current pricing page and service agreement before you rely on this option.
What drives the cost of each option
Clerk and self-hosted ZITADEL charge for different things, so a fair comparison starts by listing components rather than totals. Each card below names who is paid, whether the cost is one-time or recurring, and what moves it up or down.
Clerk subscription and metered charges
Recurring. Clerk bills a plan fee plus charges tied to monthly retained users and enterprise SSO connections. Pull the current tiers and overage rules from your own contract and Clerk's pricing page, not from memory, because these change. Model your retained-user count for the next two renewals, and list every enterprise connection your customers ask for, since each one can add a charge. Also check dashboard seats for your engineers and admins.
Engineering time for login screens
Recurring. Clerk ships prebuilt components, so most of the login and account UI comes from the vendor. With ZITADEL you rely on its hosted login and theming, and your team owns the glue code in your application. Count the screens you customize, the frontend work for each, and who maintains them after each release. Ask your partner to scope this in writing by screen and flow, including password reset, passkey enrollment and organization switching.
ZITADEL infrastructure and PostgreSQL
Recurring. Self-hosting means compute for ZITADEL, storage, load balancing, and a PostgreSQL database that is either run by your team or bought as a managed service. ZITADEL supports PostgreSQL 14 through 18, and Kubernetes with the official Helm chart is the documented route to high availability. The main drivers are user volume, the number of instances, and whether you need multiple regions or an active standby. Ask for the sizing assumptions behind any quote.
Backup, recovery and on-call coverage
Recurring. Backups of the identity database, tested restores, and a documented recovery time are a cost Clerk absorbs and your team absorbs with ZITADEL. A login outage stops every user, so the on-call rota is a real cost driver, not an overhead line. Ask for the backup schedule, restore test frequency, and who is paged at night. Also confirm whether the quote covers disaster recovery exercises or only setup.
Upgrades and security patching
Recurring. ZITADEL releases move quickly, and each upgrade needs staging tests, a database migration plan, and rollout across your environments. Clerk handles this on its side, so the work shifts to you. Track the release cadence in the GitHub releases page, and plan for at least one upgrade cycle per year in your budget. Ask whether a retainer covers upgrades, security advisories and emergency patches, and what response window it commits to.
One-time migration and licensing review
One-time. Moving users, password hashes, organizations and enterprise connections is a fixed project. Clerk password hashes must be exported and imported so users keep their passwords, and each customer connection must be remapped to ZITADEL organizations. Also budget for a license review, since ZITADEL's core is AGPL-3.0, which affects how you ship any modified code. Request a written scope listing each data type, test plan and cutover steps.
What moving from Clerk to ZITADEL involves
The sequence turns a Clerk tenant into a self-hosted ZITADEL instance on PostgreSQL, with users, organizations and customer identity providers moved over in a controlled order and each tenant cut over only after its checks pass.
Inventory the Clerk features in use
Start by listing everything your application depends on in Clerk: organizations and memberships, enterprise SSO connections, user metadata and public or private fields, custom session claims, webhooks, and the prebuilt components in your frontend. Your engineers own this list, and product owners should confirm which features customers actually rely on. The output is a written inventory that maps each Clerk feature to the work it needs in ZITADEL, such as organizations to map, identity providers to reconnect or claims to rebuild. Treat the inventory as the scope document for everything that follows.
Export users and verify the export
Export the user list from the Clerk dashboard and pull organizations and metadata through the Clerk API, as described in the export guide. Confirm with Clerk, in writing, whether password hashes are included for your plan and which hashing algorithms appear, because this determines whether users keep their passwords. Then compare record counts against the dashboard, check that emails and external identifiers are complete, and store the export encrypted under your data handling policy. The check is a reconciled count and a sample of records you have verified by hand.
Stand up ZITADEL in a non-production environment
Deploy ZITADEL in a non-production environment using Docker Compose for a trial or Kubernetes with the official Helm chart for a production-like setup. ZITADEL uses PostgreSQL, and the database versions it supports are listed in its documentation, so confirm the version you plan to run before you provision it. Your platform team owns hosting, backups and TLS, and your identity team owns the initial configuration. The output is a working instance that signs in a test user, with backup and restore tested against the database.
Map Clerk structure to ZITADEL
Decide how Clerk's tenancy translates into ZITADEL's model of instances, organizations and projects. ZITADEL uses instances as fully isolated virtual tenants, organizations inside instances where projects and users live, and projects that group applications, roles and grants. Map each Clerk organization to a ZITADEL organization, group your applications into projects, and recreate roles from the inventory. Document the mapping in a table that your architects review. The check is that every Clerk organization and role has one named ZITADEL counterpart.
Reconnect customer identity providers
For each enterprise connection in Clerk, configure the matching identity provider in ZITADEL. ZITADEL can federate with OIDC and SAML providers, LDAP and OpenLDAP, and each customer organization can use its own identity provider. Work with each customer's identity team to confirm metadata, redirect URIs, attribute mappings and whether they need SCIM provisioning. Test one connection end to end with a test account before moving on. Clerk's per-connection fees stop only after this step completes for each customer.
Rebuild login and account screens on hosted login
Clerk's prebuilt components do not carry over, so replace them with ZITADEL's hosted login pages, or with your own frontend that calls the ZITADEL APIs. Decide which screens you need: sign in, sign up, password reset, MFA enrollment, passkey registration and account settings. Review branding, copy and error handling with your security and product teams. The output is a set of screens that pass a scripted walkthrough for each login method you support, including the passkey fallback to password login.
Run a migration with a rollback plan
Choose between bulk import of the exported users and just-in-time migration, where ZITADEL checks the old provider on first login. ZITADEL's documented migration guides cover Auth0, Keycloak, Firebase and another ZITADEL instance, so confirm with ZITADEL whether a Clerk path exists or whether a custom import script is needed. Whichever you choose, write a rollback plan that keeps Clerk active until each tenant is verified, and rehearse it in the non-production environment. For detailed import steps, use the sibling page on migrating from Clerk to ZITADEL.
Cut over one tenant at a time
Move customers in batches, starting with an internal or low-risk organization, then widening the group after each cut over. For every tenant, switch the application's identity configuration, confirm sign in for a sample of users, check that roles and organization membership resolve correctly, and monitor failed logins. Record the result and keep the rollback path open until the tenant signs off. The sequence is complete when every tenant runs on ZITADEL, Clerk has no active users, and the decommissioning steps for Clerk are signed off by your security team.
Questions buyers ask before choosing ZITADEL or Clerk
How much effort does a self-hosted ZITADEL deployment take?
Expect ongoing operating work, not just a one-time install. ZITADEL runs on PostgreSQL, and the self-hosting documentation covers Linux and macOS binaries, Docker Compose and Kubernetes, with the official Helm chart recommended for high availability. Your team owns the database backups, TLS certificates, upgrades, monitoring and an on-call rotation for login outages, since a failed identity service blocks every app that depends on it. Confirm the database version you will run against the supported range in the ZITADEL database documentation before you commit to a platform.
Can our team run ZITADEL in-house or should we hire outside help?
It depends on whether you already run PostgreSQL and Kubernetes or Docker in production and have people who can own identity as a service. Teams with that experience can usually take on the deployment, while teams new to these tools often benefit from outside help for the first build, hardening and runbooks. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ask any provider to describe who will be on call after go-live and how that support is priced.
How long does a migration from Clerk to ZITADEL take?
No duration can be stated here without a written scope, because the timing depends on how many applications, user records, custom login screens and enterprise connections you have. The main drivers are the number of Clerk organizations to map, whether you move password hashes or use just-in-time migration, how much of Clerk's prebuilt components you need to replace with ZITADEL's hosted login, and how many customer identity providers need to be reconnected. ZITADEL documents migration guides from Auth0, Keycloak, Firebase and another ZITADEL instance, which helps scope the work. Ask for a timeline that lists each of these items as a separate deliverable.
Do passkeys and MFA work the same way in ZITADEL and Clerk?
Both support passwordless sign-in, but the setup and the user interface differ, so check each flow against your requirements. ZITADEL supports passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login. With Clerk, the prebuilt components handle much of the user-facing flow, while on ZITADEL your team configures the policies and works with its hosted login pages. Test enrollment, recovery when a user loses a device, and step-up behavior for sensitive actions with a pilot group before you cut over.
Does the AGPL license affect an internal tool built on ZITADEL?
For many internal deployments, the answer depends on how you modify and distribute the software, so have counsel review your specific use. ZITADEL moved its core, Console and hosted login from Apache 2.0 to the GNU Affero General Public License 3.0 with v3.0 on 31 March 2025, while its APIs, SDKs, proto definitions, Helm charts and Terraform configurations remain Apache 2.0. The AGPL includes obligations for users who interact with a modified version over a network, so changes to the core that you offer to users may carry source obligations. Ask your legal team to review whether your planned modifications and integrations trigger them.
What should we ask for in a quote for a ZITADEL migration?
Ask for a written scope that lists every deliverable, assumption and exclusion before you compare prices. Cost comes from the components: infrastructure for ZITADEL and PostgreSQL, licenses where applicable, the migration and testing work, hardening, backup and recovery setup, documentation, and ongoing support or upgrades. Ask which costs are one-time and which recur, who is paid for each component, and what a change in user count or application count would do to the estimate. DeployOpen does not publish a price list, and a quote follows from the written scope.
Do we need a Clerk password hash export to keep users' passwords?
Yes, if you want users to keep their existing passwords without a reset, you need password hashes from Clerk and a way to import them into ZITADEL. Without them, you can still move user profiles and use just-in-time migration, where users sign in on the new system and the password is verified against the old one, or you can require a password reset. Check with Clerk what its export includes for your plan and account before you plan the cutover, and test the imported hashes with a sample of accounts. Users with passkeys or social logins may need to re-enroll those methods on the new platform.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Clerk vs ZITADEL, we help you test whether ZITADEL fits your login, B2B and SSO requirements, then build and hand over the environment if you decide to move.
How we scope
- We start with your current Clerk setup: login methods, organizations, enterprise connections and user volume.
- We agree the ZITADEL scope in writing, including instances, organizations, projects and identity provider mappings.
- We confirm your hosting target, PostgreSQL version and whether AGPL-3.0 terms fit your distribution model.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before any work starts.
How we build
- We deploy ZITADEL with Docker Compose or Kubernetes on PostgreSQL in your infrastructure, following your security baseline.
- We configure passkeys, MFA policies and federation with your existing identity providers over OIDC or SAML.
- We build the hosted login and account flows that replace Clerk's prebuilt components, and test them against your applications.
- We run security testing on the login flows and APIs before any user moves across.
How we hand over
- We plan and rehearse user export and import, including how password hashes are handled, and document the verification steps.
- We deliver runbooks covering backup, restore, upgrades and the operating tasks your team takes on.
- We prepare documented controls and evidence for your compliance assessments, while independent auditors issue any formal reports.
- We walk your engineers through the environment so they can run it without us.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We track ZITADEL releases and plan upgrades against your change windows, with the scope agreed in writing.
- Quotes follow from the written scope, so you can compare the one-time migration with recurring support costs.
- We confirm what is in and out of scope before each change, so responsibilities stay clear for your team.
