Which to choose: Okta or ZITADEL for your identity platform
The question for this page is whether your organization should keep Okta as the single identity platform for employees and business partners, or move that workload to self-hosted ZITADEL, which is built around tenants, organizations and projects. Renewals and per-user price changes usually trigger the review, but the deciding factor is often the need to serve several distinct partner organizations, each with its own login rules, from one platform. Okta fits when you want the vendor to run the service, when your application catalog and admin team already depend on Okta's integrations, and when a suite of per-user products covers the features you need. Okta also carries the operational burden of uptime and patching off your team, which matters most for organizations without a platform engineering group.
ZITADEL fits when self-hosting is a requirement, whether for data location, cost control or independence from one vendor. Its instances give full data isolation for separate tenants, organizations inside an instance hold the users and projects for each partner, and each organization can federate login to a different upstream provider such as Entra ID, Okta or an LDAP directory. ZITADEL's core, Console and hosted login are licensed under AGPL-3.0, so you should confirm with legal that running a modified version as a network service and offering it to partners is acceptable. Its APIs, SDKs and Helm charts remain Apache 2.0. Confirm the current feature list for your protocol and provisioning needs against the ZITADEL repository.
The decision turns on three questions. First, can your legal team accept AGPL-3.0 obligations for the server code, or do you need a different license posture? Second, who will run PostgreSQL (supported versions 14 through 18) and Kubernetes for high availability, and does your team have that capacity or will you contract it? Third, how many distinct customer or partner organizations must be isolated, because a small number of internal tenants may not justify the self-hosting effort. Ask any implementation partner for a written scope covering the database, backup, upgrades and on-call ownership before you compare prices.
Which option fits which scenario
This table maps common organizational scenarios to the platform that usually fits better, with the reason and the conditions that would reverse the answer. Read each row against your own workforce, partner model and team skills, then check the conditions column before you decide.
| Scenario | Better fit | Reason and conditions that change the answer |
|---|---|---|
| One workforce, SSO and MFA only, no partner tenants | Okta or a single-realm self-hosted IdP | ZITADEL's instance and organization model adds value mainly when many separate tenants exist. If you only need employee SSO, a simpler product may carry less operational weight. Revisit if partner onboarding grows. |
| Partners or customers each need their own identity provider | ZITADEL | ZITADEL lets each organization use a different identity provider, such as Entra ID, Okta, LDAP or OIDC, inside one instance. Confirm the exact per-organization configuration with ZITADEL's documentation for your version. |
| Platform team already runs Kubernetes and PostgreSQL | ZITADEL | ZITADEL supports Kubernetes with the official Helm chart and PostgreSQL 14 to 18. Existing cluster and database skills lower the operating burden. Check that your PostgreSQL version falls in the supported range. |
| No Kubernetes staff and a small operations team | Okta, or Keycloak or authentik on a simpler deployment | ZITADEL also runs with Docker Compose or Linux binaries, but high availability is recommended on Kubernetes. Without Kubernetes skills, the patching, backup and upgrade load may outweigh the benefits. Consider a managed or DeployOpen-supported deployment. |
| Legal review flags AGPL-3.0 for the identity platform | Okta, or Keycloak (Apache 2.0) if the concern is strict | ZITADEL's core, Console and hosted login are AGPL-3.0 since v3.0, while APIs, SDKs and Helm charts stay Apache 2.0. Whether AGPL obligations apply depends on how you modify and offer the software, so take the question to counsel. |
| Need SAML and SCIM for many enterprise apps | ZITADEL or Keycloak | ZITADEL implements OIDC, OAuth 2.0, SAML 2.0 and SCIM v2. Confirm each target application's SAML and SCIM requirements, since some need vendor-specific attributes. |
| Migrating from Okta with many existing apps and policies | Depends on app and policy count | Okta policies, app assignments and MFA enrollments must be rebuilt in either platform. Inventory them first. Passwords and factors generally cannot be exported from Okta, so plan re-enrollment regardless of target. |
| Data must stay in your own data center or air-gapped network | ZITADEL or Keycloak, self-hosted | Okta is a cloud service. Both self-hosted options can run inside your boundary. Confirm offline update and licensing needs for your environment before committing. |
How ZITADEL instances, organizations and projects isolate tenants
ZITADEL separates tenants at three levels, and the first design decision is which level carries the isolation you need. An instance is a virtual tenant with full data isolation, so it is the right boundary when two customers or business units must never share users, policies or configuration. Inside an instance, organizations hold the users and the projects they work on. Projects sit at the bottom and group applications, roles and grants. Keeping these three levels distinct lets you give a partner company its own organization and its own identity provider without splitting the whole deployment.
Okta organizes workforce tenants differently. A single Okta org is typically the unit for employees, groups and app assignments, and separate orgs are used for separate directories or environments. That model fits one company well. ZITADEL's extra levels fit an operator who serves employees and business partners from one platform, because each partner organization can federate to a different identity provider, such as its own Entra ID tenant or a Keycloak realm, while your applications stay in shared projects. The comparison is about shape, not capability: confirm with Okta which of its constructs maps to your current structure before you assume a match.
Before go-live, an operator should decide four things in writing. First, how many instances you need, because instance boundaries are the hardest to change later. Second, which organizations exist, who administers each one, and which login policies and identity providers apply to it. Third, how projects, roles and grants map to your applications, so that a partner receives access to specific applications only. Fourth, how you will test isolation: create a user in one organization and confirm that a second organization cannot see or authenticate it. Check the exact behavior of instance and organization settings against the current ZITADEL documentation for your version, and ask for a written isolation test plan from anyone quoting the work.
Capability comparison: Okta and self-hosted ZITADEL
This table compares Okta Workforce Identity with self-hosted ZITADEL on the protocols, upstream federation, organization structure, passkeys, device login, migration paths and hosting options that matter when one identity platform serves employees and business partners. Read each row against your current Okta contract, because Okta-side coverage depends on which suite and add-ons you license. Where ZITADEL's documented coverage is narrower or still needs your own testing, the cell says so.
| Capability | Okta Workforce Identity | Self-hosted ZITADEL |
|---|---|---|
| OIDC and OAuth 2.0 | Supported as core SSO and authorization server functions in Okta suites; confirm custom authorization server limits in your edition | Implements OpenID Connect and OAuth 2.0, including the device authorization grant |
| SAML 2.0 | Supported for SAML app integrations; confirm the app catalog coverage for your line-of-business apps | Implements SAML 2.0 for applications and federation |
| SCIM 2.0 provisioning | Provisioning to and from connected apps is a licensed capability; confirm which connectors your suite includes | Provides a SCIM v2 service provider interface for standardized user lifecycle management |
| LDAP | Delivered through Okta's directory agents and LDAP interface; confirm the add-on and agent requirements in your contract | Supports LDAP and OpenLDAP as federated identity providers; LDAP as a directory service for legacy clients needs separate confirmation |
| Federation to upstream identity providers | Connects to external identity providers; confirm the exact providers included in your edition | Federates login with Google, GitHub, GitLab, Apple, Entra ID, Okta, Keycloak, LDAP and any OIDC-compliant provider |
| Per-organization identity provider | Possible through multiple identity provider routing rules; confirm how routing scales across your tenant model | Each customer organization in ZITADEL can use a different identity provider within one instance |
| Tenant and project structure | Organized around org, groups and app assignments; multi-tenant customer isolation is a separate Okta product | Instances give full data isolation, organizations hold users and projects, and projects group applications, roles and grants |
| Passkeys (FIDO2 and WebAuthn) | Supported as an authenticator; confirm passkey policy options and enrollment flows in your tier | Passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login |
| Device authorization grant | Confirm device flow support for smart TVs and CLI tools in your configuration | Provides the device authorization grant for devices such as smart TVs |
| Migration guides | Okta's own export and import paths are covered in its support documentation; confirm migration tooling for your target | Documented migration guides from Auth0, Keycloak, Firebase and another ZITADEL instance, including just-in-time migration |
| Hosting options | Okta-hosted cloud service only; data location follows Okta's regional cells | Self-hosted on Linux or macOS binaries, Docker Compose or Kubernetes, with PostgreSQL 14 through 18 and the official Helm chart for high availability |
Where identity data lives and who controls it
Okta Workforce Identity runs as Okta's cloud service, while self-hosted ZITADEL runs in an account or data center the organization controls. The cards below cover where identity data sits, how each deployment is hosted, what evidence the organization must produce itself, and who can see logs and support access.
Where identity data is stored
Okta holds directory records, sessions and policy data in its own cloud, so data location follows Okta's regional cell and sub-processor arrangements. With ZITADEL, the database and any event data sit in the PostgreSQL instance you provision. Ask Okta in writing which region hosts your tenant and which sub-processors touch identity data, then map the same questions to your own PostgreSQL location.
Hosting models for self-hosting
ZITADEL documents Linux and macOS binaries, Docker Compose and Kubernetes. The official Helm chart on Kubernetes is the option the project recommends for high availability. Choosing a model decides who patches the operating system, the container runtime, the cluster and the database. Confirm the chosen model against the current self-hosting guide before you commit to an architecture.
Compliance evidence you produce
Okta's certifications cover Okta's own service, but they do not show how your tenant policies, admin roles or access reviews are operated. A self-hosted ZITADEL deployment moves those controls into your environment, so your auditors will ask for evidence of hardening, backups, patching and access to the database and cluster. Certifications for either side come from independent auditors, not from the vendor or from DeployOpen.
Support and administrative access
With Okta, Okta staff can access tenant data under its support processes, and your administrators act through the Okta console and APIs. With self-hosted ZITADEL, you decide who holds database credentials, cluster access and instance administrator roles. Write down who can read identity records, who can run database queries and how emergency access is granted and revoked.
Logs and audit trails
Authentication and administration events in Okta are available through its System Log. In ZITADEL, you choose where logs are shipped, how long they are kept and who can read them. Decide the retention period and export path before go-live, because a self-hosted deployment is only as good as the log pipeline you build around it.
Data export and exit
Your exit path depends on what can leave each platform. Okta's data can be pulled through reports and the List Users API, but configuration such as policies usually needs rebuilding. ZITADEL's data sits in your own PostgreSQL database, so backup and restore procedures become your responsibility. Ask for the exact export formats and tested restore steps in writing before relying on either path.
What the AGPL-3.0 license change means for ZITADEL users
The first thing to establish is which parts of ZITADEL now carry AGPL-3.0. 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. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain under Apache 2.0. For an Okta replacement, this split matters because the identity server, the admin console and the login pages that your employees and partners see are the parts under AGPL-3.0, while the Helm chart and Terraform modules you use to deploy them are not. Read the license files in the repository for the exact boundary before you draft internal policy.
AGPL-3.0 obligations are most likely to matter when you modify ZITADEL and make the modified version available to users over a network. The AGPL extends the source-availability duty of the GPL to that network use. Internal use of an unmodified release by your own workforce is a different case from customizing the Console or login pages for business partners, so ask counsel to map each planned change to a use case. Include your partner-facing login branding, any custom identity provider plugins and any patches you carry against upstream. Counsel should also review whether any downstream product you build on ZITADEL will be distributed to third parties.
Confirm the version before planning. The latest release listed is v4.19.5, dated 15 October 2026, so check the zitadel/zitadel releases page on the day you start, then pin the version you test and the one you deploy. Record the version in your change management system, because license review, security patching and upgrade testing all refer to it. If your team needs a different release line, ask counsel to re-check the license terms that apply to that version.
How a move from Okta to ZITADEL usually proceeds
The sequence moves identities, applications and sign-in methods from Okta into ZITADEL one application at a time, so each cutover can be checked and reversed before Okta is retired. The output is a tested ZITADEL tenant model, a verified identity import, and a dated decommission record for Okta.
Inventory applications, federation and Okta configuration
Your team lists every application connected to Okta, the protocol each one uses (OIDC, SAML, SCIM or proxy), the Okta sign-in policies and MFA rules that apply, and any Active Directory or LDAP sources feeding Okta. DeployOpen can run this inventory with your identity and application owners if you prefer a fixed-scope engagement. It is done when every application has an owner, a protocol and a cutover risk rating.
Map Okta structures to ZITADEL instances and projects
Decide how Okta groups, app assignments and policies translate into ZITADEL instances, organizations and projects. Instances give full data isolation, organizations hold the users and projects, and projects group applications, roles and grants. For an employee and partner setup, one organization per partner with its own identity provider is a common pattern to test. The output is a written mapping document reviewed by the security and application teams.
Stand up ZITADEL and confirm the database and HA design
Deploy ZITADEL on your chosen target, either Docker Compose for a single-node test or the official Helm chart on Kubernetes for high availability, backed by PostgreSQL 14 through 18. Confirm backup, restore and upgrade procedures with your platform team before any user data arrives. It is done when a test instance passes a restore drill and the operations owner has signed off.
Export identities from Okta and confirm what is included
Export active users using the Okta Password Health report CSV, the List Users API with a filter, or a community tool, as Okta documents. Standard exports carry profile attributes and status, but not password hashes, so confirm with Okta what your tenant provides and plan for it. Check the exported record count against Okta's directory and document any attributes that did not come across. The output is a validated user file in a restricted location.
Plan password and passkey re-enrollment
Because password hashes are usually unavailable from Okta, decide how users will sign in on day one. Options include just-in-time migration with the ZITADEL migration guidance, where credentials are checked against the source on first login, or a forced reset with passkeys offered as the preferred method, with password fallback. Communicate the process to users and the help desk, and record which users have enrolled. It is done when the re-enrollment path is tested with a pilot group.
Run migration with a pilot group and reconcile results
Import users into the target organization, or activate just-in-time migration, and run a pilot with a small group of non-critical applications. Compare group membership, role grants and login outcomes against Okta for each user type. Fix mapping errors before widening the pilot. The output is a signed reconciliation report showing which users, roles and applications behaved as expected.
Cut over applications one at a time
Repoint each application's OIDC or SAML configuration from Okta to ZITADEL in a planned change window, starting with the least critical. Keep the Okta app active in parallel until the application owner confirms sign-in, logout, and role-based access. Verify SCIM provisioning where it is in use. Each cutover is complete when its test cases pass and the rollback step is documented.
Decommission Okta and keep evidence
After every application has run on ZITADEL for an agreed period, disable Okta sign-in, revoke API tokens, remove app integrations, and retain the exported configuration and reconciliation records under your retention policy. Confirm with Okta how long your contract and data access continue during wind-down. The output is a decommission record that compliance and audit teams can review, with the independent auditor responsible for any formal assessment.
Questions buyers ask before choosing ZITADEL over Okta
What drives the cost of self-hosting ZITADEL compared with Okta's per-user suites?
The main cost difference is that Okta bills per user under a suite, with an annual minimum of $1,500 as stated in Okta's published terms or your own contract, while self-hosted ZITADEL carries no software license fee for the core you run. Your costs become infrastructure (Kubernetes nodes, PostgreSQL, backups, load balancing, monitoring), the people who operate them, and any support subscription you choose to buy. Infrastructure and labor scale with availability targets and environments, not with each user added. Ask any implementation or support partner for a quote built from a written scope that lists each component, who pays for it, and what recurs each year.
How much operational effort do Kubernetes and PostgreSQL add for ZITADEL?
Effort depends on whether your team already runs Kubernetes and PostgreSQL in production. ZITADEL supports self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and the project recommends a Kubernetes cluster with the official Helm chart for high availability. The database is PostgreSQL, with versions 14 through 18 supported, so your database team needs to own backups, patching, failover and version planning. Confirm with ZITADEL's self-hosting documentation which configuration your availability requirements call for before sizing the platform.
Can our own team migrate from Okta to ZITADEL without outside help?
A capable platform team can migrate in-house if it has the time, the skills and a clear test plan, but the work is more than a data copy. ZITADEL documents migration guides from Auth0, Keycloak, Firebase and another ZITADEL instance, and it describes approaches such as just-in-time migration, which can move users as they sign in. Okta itself does not provide a password export path in the same way, so plan how users re-enroll credentials and MFA, and rebuild application integrations and policies by hand. Review the ZITADEL migration guides and decide which parts your staff will carry.
How long does an Okta to ZITADEL migration take, and what sets the timeline?
No duration is established by the researched facts for this migration, so treat any single number you hear as unverified until it is tied to your scope. The timeline is set by the number of applications and their protocols (OIDC, SAML, SCIM), how many customer or partner organizations need their own identity provider, the user migration method you pick, and how much re-enrollment of passkeys and MFA your users will tolerate. Parallel running and cutover windows also add time. Ask for a written plan with phases, owners and exit criteria for each application.
What does the migration need from our internal staff?
Expect to involve identity administrators who know your Okta apps, groups and policies, application owners who will test sign-in and claims, and platform engineers who will run the Kubernetes and PostgreSQL environment. Security and compliance staff should review access policies, logging and the evidence that controls are working. Someone must also own user communication, since passkey and MFA enrollment usually needs direct guidance from the help desk. Agree these roles in the scope so the work does not stall waiting for people who were never assigned to it.
Does the AGPL-3.0 license apply to how we plan to use ZITADEL?
The license depends on how you use and distribute the software, so have your legal counsel confirm the position for your case. ZITADEL moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with version 3.0 on 31 March 2025, while APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. Internal use of an unmodified server differs from offering a modified version to outside users over a network, which is where AGPL obligations typically require attention. Ask ZITADEL directly about commercial terms if your legal team needs one. Read the ZITADEL blog post on the license change before the review.
When is an outside implementation partner worth engaging for this migration?
An outside partner is worth considering when your team lacks Kubernetes, PostgreSQL or identity engineering capacity, when the migration must finish before a renewal date, or when compliance evidence has to be prepared alongside the build. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For Okta vs ZITADEL, we start from the tenant model you need, then build, test and document a ZITADEL deployment that you run and own.
How we scope
- We confirm which employee and partner populations sit in each ZITADEL organization and which instances, if any, need full data isolation.
- We inventory Okta apps, SAML and OIDC integrations, SCIM provisioning and any directories that feed identity today.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- We deploy ZITADEL on Kubernetes or Docker Compose with PostgreSQL in your environment, sized to your availability targets.
- We configure identity provider federation per organization, passkey policies with password fallback, and SCIM 2.0 provisioning.
- We test login flows, token issuance, backup and restore, and upgrade paths before any application cuts over.
How we hand over
- You receive architecture records, configuration as code, runbooks and an application-by-application migration plan.
- We document the Okta-to-ZITADEL mapping for apps, policies and user data, and list what must be re-enrolled, such as passkeys.
- Your administrators are trained on instance, organization and project administration before handover.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can prepare identity controls and evidence for compliance assessments, while independent auditors issue any reports.
- We can scope a retainer that covers ZITADEL upgrades, PostgreSQL maintenance and periodic security testing of your login flows.
