Clerk cost vs self-hosted ZITADEL: where the money actually goes
Self-hosting ZITADEL moves identity spend from metered vendor fees to a one-time implementation project plus recurring infrastructure and operations. Whether that shift saves money depends on three things: your monthly retained user count, how many enterprise SSO connections you run and how many people your team can spare to operate the service. Clerk's current plan fees, retained user tiers and per-connection charges must be taken from Clerk's own pricing page, since those numbers change and are not part of the researched facts for this page.
Start by listing every Clerk line item on your invoice: the base plan, retained user overage, each enterprise connection and any dashboard seats your staff pay for. Then price the self-hosted side by component. ZITADEL's core is licensed under AGPL-3.0 since v3.0, so the software itself carries no license fee, but the AGPL terms matter if you modify it and offer it to users, and your counsel should confirm that position. Its database is PostgreSQL, and ZITADEL supports PostgreSQL 14 through 18, so your DBA team and any managed database service are a recurring cost. The current release is v4.19.5, released on 15 October 2026, and each upgrade is staff time you should budget for.
Ask any implementation partner for a written quote that separates one-time work (installation, the Clerk user and password hash migration, login screens, connection setup and cutover testing) from recurring work (hosting, database backups, patching, monitoring, on-call and upgrades). Ask whether support is priced per year or per incident. Build two illustrative scenarios with your own user counts and connection counts, and set the break-even month against your Clerk renewal date. Keep the migration plan in view too, because exporting password hashes and enterprise connections is where the schedule usually slips.
Which cost components move between Clerk and self-hosted ZITADEL
This table lists each cost component on the Clerk side and the matching item on a self-hosted ZITADEL side, and marks whether it is one-time or recurring. Use it to build your own comparison from the current Clerk pricing page and your quotes, since no vendor prices are shown here. The main takeaway is that most of the self-hosted cost sits in people and operations, not in the software license.
| Cost component | Clerk (commercial side) | Self-hosted ZITADEL | One-time or recurring |
|---|---|---|---|
| Plan fees | Subscription plan tier, checked on Clerk's pricing page | No license fee for the AGPL-licensed core; confirm current terms with ZITADEL | Clerk: recurring. ZITADEL: none for the core |
| Retained user tiers | Charged by monthly retained users, with tiers and overage | Not metered by user count; cost scales with hosting capacity | Clerk: recurring. ZITADEL: infrastructure only |
| Enterprise SSO and Directory Sync connections | Per-connection fees for SAML, OIDC and Directory Sync, per Clerk's pricing | Connections configured without per-connection fees; confirm with ZITADEL Cloud terms if relevant | Clerk: recurring. ZITADEL: none in software |
| Dashboard seats | Paid seats for team members on the Clerk dashboard, if your plan charges them | No seat fee; admin access managed through your own identity and roles | Clerk: recurring. ZITADEL: none |
| Infrastructure | Included in the hosted service | Compute, load balancers and storage for ZITADEL on your cloud or data center | Recurring, driven by high availability design |
| PostgreSQL | Not visible to you | Managed or self-run PostgreSQL 14 to 18, with backups and replication | Recurring, with a one-time setup |
| Implementation | Initial SDK and dashboard setup by your developers | Deployment, hardening, hosted login branding and integration, quoted by written scope | One-time |
| Data migration | Export of users and password hashes from Clerk | Import and verification in ZITADEL, including just-in-time options if used | One-time |
| Support | Vendor support tier included in your plan | Internal on-call or a support retainer you buy separately | Recurring |
| Upgrades and testing | Handled by Clerk | Your team or a partner applies ZITADEL releases and retests login flows | Recurring |
| Internal skills | Developers integrate the SDK; little operations work | Staff need PostgreSQL, Kubernetes or Docker and identity operations skills | Recurring, often the largest item |
What moves the comparison most for your team
Six factors decide whether a hosted Clerk bill or a self-run ZITADEL deployment costs less for your team. Several push in opposite directions, so each card explains which side each factor favors and what to measure before you ask for a quote.
Retained user count and growth
Clerk's charges scale with monthly retained users, so a rising user base raises the hosted bill in steps defined by its plan tiers. Self-hosted ZITADEL adds cost mainly through database storage, compute and backups, which grow more gradually with users. Pull your current retained user count and six-month growth from Clerk, then ask your vendor or integrator how the self-hosted footprint scales with that number.
Number of enterprise SSO connections
Clerk charges per enterprise SSO connection, so customers that each bring their own SAML or OIDC identity provider add a recurring line item. In ZITADEL, each customer organization can use a different identity provider without a per-connection fee, which shifts the cost into setup and testing effort. List every active connection, its protocol and whether Directory Sync is in use before comparing totals.
Required availability and multi-zone design
Clerk handles availability as part of its hosted service. A self-hosted ZITADEL deployment must be designed for it, and the official documentation recommends Kubernetes with the official Helm chart for high availability. Multi-zone designs add nodes, load balancing and database replicas, all of which are recurring costs. Write down your uptime target and whether a regional outage must be survivable before pricing either side.
Data residency and hosting location
If customer identity data must stay in a specific region or your own data center, the hosted option may not meet the requirement, and the self-hosted route becomes a compliance cost rather than a preference. Self-hosting moves responsibility for location, access controls and backups to your team or integrator. Confirm with legal and your customer contracts which regions and subprocessors are acceptable, then price the infrastructure in those places.
Edition and support level
ZITADEL is licensed under AGPL-3.0 for its core, and the Cloud option and any paid support are separate purchases with their own terms. Support contracts, response times and upgrade assistance add recurring cost if you need them, and so does a retainer for ongoing operations. Ask the vendor exactly which features and support levels each plan includes, and whether the AGPL terms affect how you ship changes to users.
In-house Kubernetes and PostgreSQL skills
Self-hosted ZITADEL runs on PostgreSQL, with versions 14 through 18 supported, and is typically operated on Kubernetes for high availability. Teams that already run these platforms carry lower operating cost, while teams without them either hire, train or pay an implementation partner for ongoing operations. Count the people who can patch the database, rotate keys, restore backups and upgrade the identity service, and note who is on call for it.
How to build the cost model with your own numbers
This sequence turns your current Clerk bill into a three-year comparison against self-hosted ZITADEL, using your own user counts, staff rates and migration scope. The result is a model your finance and security leads can challenge line by line.
Pull your current Clerk invoices and usage
Finance or the account owner collects the last twelve months of Clerk invoices, plan details and usage reports, including any overage charges and enterprise SSO line items. Keep the invoices as the baseline, since the figures you enter later must reconcile to what you actually paid. Done means every recurring and variable charge is listed by month with its source document attached.
Count retained users and SSO connections monthly
The product owner and an engineer extract monthly retained user counts and the number of active enterprise SSO connections and directory sync connections from Clerk's dashboard, then compare them with the tier boundaries on your plan. Track peaks as well as averages, because tiered pricing charges for the high months. Done means you have a twelve-month table that matches the invoice totals within a difference you can explain.
Inventory the self-hosted infrastructure and database needs
The platform team lists the compute, load balancing, backup storage, monitoring and PostgreSQL resources ZITADEL would need in your cloud account or data center, including a non-production environment. Use the supported PostgreSQL versions and the deployment method your team already runs, Docker Compose or Kubernetes, as the basis. Done means each resource has an owner, a monthly cost from your own pricing sheet, and a note on whether it is one-time or recurring.
Cost the migration from Clerk's export path
Engineers estimate the work to export users and any hashed passwords from Clerk, map organizations and enterprise connections, and run ZITADEL's migration approach, such as just-in-time migration, against your application. Ask the vendors and any implementation partner for a written scope, since the amount of login UI to replace drives most of this cost. Done means each migration task has a named owner and an effort range that a quote can be compared against.
Estimate operating hours at your own staff rates
The platform and security leads estimate monthly hours for upgrades, certificate and database maintenance, backups, incident response and on-call, then multiply those hours by your internal loaded rates. Add any paid support or retainer you decide to buy, using written quotes rather than estimates. Done means the operating cost is a monthly figure with its hour assumptions written next to it, so a reviewer can change one input and see the result.
Run a three-year comparison with illustrative inputs
Finance builds a three-year table with Clerk spend, including projected user growth and SSO connections, against ZITADEL's one-time migration, infrastructure, support and operating costs. Label any sample numbers as illustrative and replace them with your own rates before circulating the model. Done means the table shows cumulative cost by year, the break-even point if one exists, and a sensitivity line for user growth and staff time.
Review assumptions and document open questions
The CISO, CTO and finance lead review each assumption, flagging items to confirm with Clerk, ZITADEL, a support provider or your own environment, such as contract terms, data residency needs and feature gaps. Record which figures came from invoices, which came from quotes and which are internal estimates. Done means the model has a signed-off assumptions list and a short list of questions that must be answered before the decision.
How one-time migration work shapes the first-year number
The largest one-time items in a move from Clerk to self-hosted ZITADEL are implementation work, the user export, the rebuilt login screens and the mapping of organizations and enterprise connections. Those items, not the software license, decide most of the first-year number, because ZITADEL itself carries no license fee on your own infrastructure. Before you scope anything, confirm one question with Clerk and with your own export: whether password hashes come out of Clerk's export in a form ZITADEL can import. If hashes cannot move, every user faces a reset or a just-in-time path, and the project timeline and support load change with it.
The export is the first checkpoint. Run it in a non-production environment, count the users, and check that the fields you need (identifiers, email addresses, verification state, metadata and organization membership) are present. Organizations and enterprise connections are usually exported separately from the user list, so your team should map each Clerk organization to a ZITADEL organization inside an instance and decide how each customer's SAML or OIDC connection will be recreated. ZITADEL documents migration guides and just-in-time migration, which can move users on their next sign-in. That approach reduces bulk import risk but adds a long tail of work to keep the old and new systems running side by side.
The other large block is interface work. Clerk's prebuilt components do not carry over, so your team either builds sign-in, sign-up, account and organization screens against ZITADEL's APIs or uses its hosted login, then tests each flow, passkey enrollment and fallback to password login. Ask any implementation partner for a written scope that lists each screen, each connection and each data check, and the assumptions behind them, including the hash handling you confirmed. Treat the migration as a fixed, documented project with its own acceptance tests, so the first-year figure reflects known work instead of an estimate made before the export was checked.
Who runs ZITADEL, and what each option costs to own
This model fits organizations that already run Kubernetes and have a platform team that owns clusters, ingress, backups and certificates. ZITADEL recommends a Kubernetes cluster with the official Helm chart for high availability, and the PostgreSQL database it depends on (versions 14 through 18 are supported) becomes a service your team must size, patch and back up. Most of the recurring cost is staff time and the cloud resources underneath, not the software.
- Cluster and load balancing: nodes, ingress, TLS certificates and the network paths that front the login pages and APIs.
- Managed or self-run PostgreSQL: replication, point-in-time recovery, minor version upgrades and capacity planning for the identity data.
- Helm chart lifecycle: reviewing chart and ZITADEL release notes, testing upgrades in a non-production instance and scheduling rollouts.
- Skills required: Kubernetes operations, PostgreSQL administration, OIDC and SAML troubleshooting, and secrets handling for signing keys.
- Monitoring and on-call: login availability alerts, certificate expiry and a runbook for identity outages, which affect every application that depends on sign-in.
Before you commit, confirm with your platform team how many hours a month they can give to identity operations, and ask ZITADEL and your cloud provider which managed database and cluster tiers they support for your expected load.
ZITADEL documents self-hosting with Docker Compose and with Linux or macOS binaries, which suits pilots, internal tools and smaller customer populations where a full cluster would be disproportionate. The trade-off is that a single host carries the identity service, the database and the reverse proxy, so the recovery plan matters more than the initial install. Recurring cost is mostly the host, the backup target and the time to keep it patched.
- Single host and virtual machine: one server or VM with enough CPU, memory and disk for ZITADEL and PostgreSQL, plus a second host or snapshot target for recovery.
- Backups and restore tests: regular PostgreSQL dumps or snapshots, stored off the host, and a restore test you have actually run.
- Certificates and reverse proxy: TLS termination, renewal automation and hostname changes for the login domain.
- Skills required: Linux administration, Docker, PostgreSQL basics and a clear owner for patch windows.
- Upgrade path: planning the move from a single host to Kubernetes if availability requirements grow later, since that changes the operating model.
Ask your team to write down the recovery time they can accept for a failed host, then confirm whether that meets the customer and internal commitments you already make for sign-in.
Some organizations prefer to buy the build and then the ongoing operation from an implementation partner. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. This model moves cost from internal hiring to a defined project fee plus a recurring support fee.
- One-time project: architecture, deployment, identity migration, integration with your applications and documentation, priced from the written scope.
- Retainer: ongoing support, upgrades and continuous security testing, which recurs for as long as you keep the arrangement.
- Client-side costs that remain: your cloud accounts, database service, backups and any licensing for adjacent tools, which the scope should name.
- Internal skills still needed: an accountable owner, someone who approves changes, and staff who take over the runbooks.
- Exit terms: how documentation, configuration and data are handed back if you change providers.
When you request a quote, ask for the scope split into one-time and recurring items, the named deliverables, the support hours or response model included, and who holds the cloud and database accounts.
Questions buyers ask before comparing Clerk and ZITADEL costs
How long does a migration from Clerk to ZITADEL take?
No single duration fits every team, and the answer depends on the scope you agree in writing. The main drivers are how many user records and password hashes must move, how many applications and redirect URIs must switch over, whether Clerk organizations map cleanly to ZITADEL organizations and projects, and how many enterprise connections you rebuild. Login screens also take time, because Clerk's prebuilt components must be replaced with ZITADEL's hosted login or your own interface. Ask any provider, including DeployOpen, to split the plan into phases with clear completion criteria, and inventory your applications and integrations before anything is scoped.
Can an internal team run self-hosted ZITADEL without outside help?
Often yes, if the team already runs production services on Kubernetes or Docker, operates PostgreSQL and owns on-call duties for identity. ZITADEL documents self-hosting with Linux and macOS binaries, Docker Compose and Kubernetes, and recommends the official Helm chart for high availability. The harder question is staffing. Someone must handle upgrades, certificate rotation, backups, monitoring, sign-in incident response and security patches. Teams that lack that depth often bring in an outside partner for setup, hardening or ongoing support, and DeployOpen offers both fixed-scope engagements and retainers. Before you commit, ask your team to name an owner for each operational task.
What PostgreSQL skills does a self-hosted ZITADEL deployment need?
ZITADEL uses PostgreSQL as its database, and the documentation lists versions 14 through 18 as supported. Your team needs to size and provision the database, configure backups and point-in-time recovery, test restores, plan minor version updates, and monitor connections and storage. For high availability, the database layer must be designed alongside the Kubernetes deployment so failover behavior is tested before go-live. If your cloud provider offers a managed PostgreSQL service, confirm that it meets ZITADEL's version and configuration requirements before you choose it.
Does ZITADEL's AGPL license change what self-hosting costs?
The license carries no fee, but it changes what you must review. ZITADEL moved its core, Console and hosted login to AGPL-3.0 with v3.0 on 31 March 2025. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. Internal use generally carries different obligations from offering a modified version to users over a network, so ask your legal counsel to confirm how the terms apply to your deployment and to any changes you make. Budget for that review as a one-time item, plus any engineering time needed to keep custom changes current with upstream releases.
Does Clerk's user export include password hashes?
Confirm this in Clerk's current export documentation and in your own dashboard before you plan the cutover, because the answer decides whether users keep their passwords after the move. If the export includes hashed passwords, check the hashing algorithm and whether ZITADEL can verify those hashes at import or through just-in-time migration. If it does not, plan for password reset emails or passkey enrollment, which add support load and may cause a sign-in drop-off. ZITADEL documents migration guides for Auth0, Keycloak and Firebase, and it is worth testing whether those approaches fit your export. Run the export on a copy of production data first.
What does a fixed-scope quote for this migration depend on?
A fixed-scope quote follows from a written scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list. The scope is usually shaped by these factors:
- The number of applications, environments and user records, and whether password hashes move
- The Clerk features in use, such as organizations, enterprise connections and user metadata
- Whether you keep Clerk's login experience or rebuild it on ZITADEL's hosted login or your own interface
- The target deployment, such as Docker Compose or Kubernetes in a cloud account or data center you control
- Backup, high availability and handover requirements
Ask any vendor for the assumptions, exclusions and acceptance criteria that sit behind the price.
Which ZITADEL costs recur after the migration goes live?
Recurring cost is mostly staff time and infrastructure, since the software license carries no fee. Recurring items include compute and storage for ZITADEL and PostgreSQL in each environment, backups and off-site copies, monitoring, security patching, version upgrades, on-call coverage, and any support contract or retainer you buy. One-time items include discovery, migration, login screen work, integration testing and documentation. Check ZITADEL's pricing page for any paid Cloud or support options, because those choices change what you pay for. Ask your provider to split the quote into one-time and recurring lines so you can compare it with Clerk's invoices line by line.
How DeployOpen scopes a fixed-price ZITADEL implementation
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move off Clerk, that means a written scope that covers the ZITADEL deployment on PostgreSQL, the user migration, the login flows and the operating runbooks, agreed before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory your Clerk plan, retained user count, enterprise connections and dashboard roles so the scope matches what you pay for today.
- Ask for the written scope to name the target: Docker Compose or Kubernetes, the PostgreSQL version and the expected instance and organization layout.
How we build
- We deploy ZITADEL on your own cloud account, data center or air-gapped network, using the deployment method named in the written scope.
- We configure OIDC applications, customer organizations, identity provider federation and passkey or MFA policies to match your existing login behavior.
- We test user export and import, password handling, SCIM provisioning and login flows in a staging environment before any cutover is scheduled.
How we hand over
- We document the architecture, configuration, backup and restore steps, and the upgrade path, so your team can run the platform after handover.
- Handover includes the cutover plan, rollback steps and the evidence list your compliance team needs for identity controls.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any formal reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the implementation.
- Retainers can cover ZITADEL version upgrades, database maintenance, backup verification and periodic security testing of the login surface.
- Ask for the retainer scope in writing to confirm response expectations, upgrade windows and which tasks stay with your internal team.
