Zitadel vs Ory: when to choose each, and what the decision turns on
Choose Zitadel when you need multi-tenant B2B identity with SAML and SCIM from a single packaged server, and your organization can accept AGPL-3.0. Zitadel bundles tenancy, SAML 2.0 and SCIM v2 into one server under AGPL-3.0, while Ory keeps its open source core (Kratos, Hydra, Keto, Oathkeeper and Polis) under Apache-2.0 and moves SAML, SCIM and organization login into the Ory Enterprise License. The license question therefore changes the shape of the decision, not just the price. Choose Ory when your team wants to build its own login experience on headless APIs and assemble components, and when the features you need are either not required yet or will be covered by a commercial agreement.
Four questions decide the choice. First, can your legal and procurement teams accept AGPL-3.0 for a server you operate, including any modifications you distribute or expose over a network? Zitadel's commercial license is the alternative to confirm with the vendor, and the Zitadel licensing document explains which directories fall under other licenses. Second, do you want a packaged server with tenancy built in, or a set of components you will wire together? Zitadel organizes tenants as instances, with organizations and projects inside them. Ory asks you to model tenancy and authorization yourself, using Keto for permissions and the APIs of Kratos and Hydra for login and tokens. Third, map each feature you require to a license: SAML, SCIM, organization login and multi-tenancy in Ory fall under the Enterprise License, so price them into the comparison before you compare architectures.
The fourth question is engineering capacity. A custom login UI on Kratos means your team builds and maintains the sign-in, recovery, MFA and passkey screens, and keeps them aligned with each Kratos upgrade. Zitadel ships its hosted login, so your team customizes rather than builds from scratch. Ask Ory which Enterprise License terms cover CVE patch timing and upgrade support, and confirm with Zitadel what its commercial license includes for support. Run a short proof of concept with one B2B tenant, one SAML connection and one SCIM sync before you commit. DeployOpen can plan and implement either path under a written, fixed scope.
Which platform fits which scenario
This table sets Zitadel and Ory against the situations that usually decide the choice, naming the better fit and the condition that makes it so. Read each row against your own constraints, because several scenarios can be met by either platform once you accept Ory's Enterprise License or Zitadel's AGPL-3.0 terms.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| B2B SaaS product where each customer manages its own users | Zitadel | Organizations inside one instance are built for customers administering their own users and identity providers. Ory can do this with Kratos multi-tenancy, but that feature sits in the Ory Enterprise License, so price it in. |
| Internal workforce SSO for employees and staff applications | Either, depending on protocol needs | Zitadel fits if you want one platform with OIDC, SAML and SCIM in the open source core. Ory fits if your team already runs Hydra or Kratos and will build the login experience around it. |
| Team building a custom login UI on APIs | Ory | Kratos is API-first and designed for teams that build their own login screens, with Hydra handling OAuth2 and OpenID Connect. Zitadel also exposes APIs, but its hosted login and Console are the default experience. |
| Team that cannot accept AGPL-3.0 obligations | Ory (Apache-2.0 components) | The Ory open source components are Apache-2.0. Zitadel's core, Console and hosted login are AGPL-3.0, and its APIs, SDKs and Helm charts are Apache 2.0. Confirm with counsel how AGPL-3.0 applies to your modifications and network use. |
| Need SAML or SCIM without a paid license | Zitadel | SAML 2.0 and SCIM v2 are part of the Zitadel open source core. In Ory, the Kratos README lists SCIM and SAML as enterprise features not in the open source version, and Polis, which provides SAML and SCIM sync, is a separate component to deploy and operate. |
| Need evidence of enterprise SLAs and CVE patch commitments | Ory with the Enterprise License | Ory states that the Enterprise License adds 24/7 support SLAs and timely CVE patches, while open source is for deployments where occasional upgrade downtime and unpatched CVEs are acceptable. Zitadel's commercial terms are set through its own Enterprise contracts, so request written support terms from Zitadel. |
| Team that needs a built-in audit trail of identity changes | Zitadel | Zitadel is event-sourced, storing every change as an event, which supports audit trails over an unlimited period. Ory stores current state in its database, so any audit history must come from logs or your own tooling. |
| Team already running PostgreSQL and wanting one database engine | Zitadel or Ory (both work) | Zitadel requires PostgreSQL 14 to 18. Ory Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, so Ory gives more choice if your standard is not PostgreSQL. |
How Zitadel and Ory are built and deployed
Zitadel ships as one server that holds instances, organizations and projects on one event-sourced store. Ory ships as separate services, each with its own database and configuration, that you assemble into a login system. The number of moving parts, and who owns each one, is the difference that matters most when you plan operations.
One server, one event store
Zitadel runs as a single identity server backed by PostgreSQL 14 to 18, and every change is written as an event. Tenancy lives inside that one deployment through instances, organizations and projects, so your platform team operates one service, one database and one upgrade path. Check how your team will handle the PostgreSQL side, since the database is the state you must back up, restore and size. Ask the vendor how event history grows over time in your expected workload.
Ory as composed services
Ory Kratos handles identities, Ory Hydra handles OAuth 2.0 and OpenID Connect, Ory Keto handles permissions, Ory Oathkeeper sits as an access proxy, and Ory Polis handles SAML, OIDC and SCIM sync. Each is a separate component with its own configuration and storage, so you design the login flow, the token flow and the authorization model across them. Plan for that integration work as ongoing engineering, not a one-time install.
Deployment options for Zitadel
Zitadel documents self-hosting on Linux binaries, Docker Compose and Kubernetes, and recommends the official Helm chart on a Kubernetes cluster for high availability. Every path still needs a PostgreSQL instance. Confirm which path matches your change control and backup tooling before you commit, because the choice shapes how upgrades and rollbacks are rehearsed.
Where the Ory services run
Ory publishes its components as separate open source projects, and Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Each service you deploy can point at its own database, which gives flexibility but multiplies the backup scopes and version pairs you track. Ask Ory which versions of each component are tested together, and decide whether one team will own the whole composition.
Upgrades and the event log
Zitadel's event-sourced store keeps a full history of changes, which supports audit trails but means schema and event evolution sit with the vendor's upgrade path. Ory's components are versioned independently, so an upgrade may touch several services in a set order. Ask each vendor for its documented upgrade sequence and rollback steps, and confirm whether your target versions need a maintenance window.
Ory Enterprise License for multi-tenant operations
Kratos multi-tenancy and organizations, along with SCIM and SAML, sit in the Ory Enterprise License rather than the open source build, and the license also covers CVE patch timing. Zitadel includes organizations and SAML and SCIM in its open source core under AGPL-3.0. Before you design the topology, confirm which components you need, which edition you will run, and who in your team owns each runtime.
Capabilities compared: tenancy, SAML, SCIM, databases and licensing
This table sets Zitadel's single open source core against Ory's headless components on the features that most often decide a shortlist. Where Ory's answer depends on a separate component or the Ory Enterprise License, the cell says so, and the licensing row shows which features sit under which terms. Confirm each Ory row against the exact component versions you plan to deploy.
| Capability | Zitadel (v4.19.5) | Ory (Kratos, Hydra, Polis) |
|---|---|---|
| OIDC, OAuth 2.0 and SAML 2.0 | Core server implements OpenID Connect, OAuth 2.0 and SAML 2.0. | Hydra is an OpenID Certified OAuth 2.0 and OIDC server. SAML comes from Polis, a separate component. |
| SCIM v2 provisioning | Built-in SCIM v2 service provider interface for user provisioning and lifecycle management. | Polis provides SCIM directory sync. Kratos lists SCIM as an enterprise feature. Confirm which path fits your setup. |
| Device authorization grant | Supports the device grant for devices such as smart TVs. | Not covered by the researched facts. Confirm Hydra's device grant support for your device types before shortlisting. |
| Passkeys and MFA | Passkeys based on FIDO2 and WebAuthn, with fallback to password login. | Kratos supports passkeys, passwordless codes and TOTP multi-factor authentication, and teams build their own login UI. |
| Multi-tenant model | Instances are virtual tenants with full data isolation. Organizations hold users, and projects group apps and roles. | Kratos multi-tenancy and organizations are Ory Enterprise License features. Confirm the tenancy design you need from the OEL. |
| Federation with external providers | Google, GitHub, GitLab, Apple, Entra ID, Okta, LDAP, Keycloak and generic OIDC or SAML. Each organization can use a different provider. | Kratos offers social sign-in. Organization login (SSO) is an enterprise feature according to the Kratos README. |
| Database support | Self-hosted deployments use PostgreSQL 14 to 18. | Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Confirm the supported database for Hydra and Keto. |
| Event-sourced audit trail | Every change is stored as an event, giving a built-in audit trail of all changes. | Confirm the audit logging each component writes (Kratos, Hydra, Polis) before relying on it for evidence. |
| License placement | Core, Console and hosted login under AGPL-3.0 from v3.0 (31 March 2025). APIs, SDKs and Helm charts stay Apache 2.0. | Kratos, Hydra, Keto, Oathkeeper and Polis are Apache-2.0. Multi-tenancy, organizations, 24/7 support and timely CVE patches sit in the OEL. |
What the AGPL-3.0 and Apache-2.0 licenses mean in practice
Zitadel moved its core, Console and hosted login from Apache 2.0 to the GNU Affero General Public License 3.0 with Zitadel v3.0 on 31 March 2025. The AGPL-3.0 license is a copyleft license, so an organization that modifies the Zitadel core and makes it available to users over a network has to make the corresponding source of those modifications available under the same terms. Plain self-hosting for internal use, with no changes to the core, is the lighter case, but legal teams should still read the license text against their own use. The APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0, so client integrations and deployment tooling carry fewer copyleft questions.
- Core and console obligations: Modifications to the AGPL-3.0 core or Console that are offered to users over a network trigger source disclosure duties.
- Apache-2.0 integration code: Applications built against the APIs and SDKs, and the Helm charts and Terraform configurations, can be governed by the more permissive Apache-2.0 terms.
- Commercial license: The vendor offers a commercial license for teams that cannot accept AGPL-3.0 terms. Ask for its scope, including whether it covers the core, the console and hosted login.
- Version lineage: Releases before v3.0 were under Apache 2.0, so confirm which license applies to each version you deploy.
- Contributions: Check whether your own patches or contributions require a contributor agreement.
Before signing, ask Zitadel in writing whether the commercial license is available for your deployment model, what it covers, and whether it changes support or upgrade terms.
Ory Kratos, Ory Hydra, Ory Keto, Ory Oathkeeper and Ory Polis are each licensed under Apache-2.0, which is a permissive license that generally does not require you to publish your modifications or your own application code. The commercial boundary sits in the Ory Enterprise License (OEL), which Ory describes as optimized builds of the same open source servers with enterprise features such as Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features not available in the open source version. Ory Network is a separate managed cloud service offered alongside the self-hosted components and the OEL.
- Open source obligations: Apache-2.0 components can be self-hosted and modified with attribution and license notice duties, without a copyleft obligation on your own code.
- Feature gating: SAML, SCIM, organization login and Kratos multi-tenancy require the OEL, so budget for it if your roadmap depends on them.
- Support and CVE terms: Open source use is described as suitable where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required.
- Drop-in builds: Ory states that OEL builds are drop-in replacements for open source installations, which you should verify during a trial upgrade.
- Managed option: Ory Network is a different delivery and contract from self-hosting, with its own terms.
Before signing, ask Ory which features are covered by the OEL in your version, what the support SLA and CVE patch windows are in writing, whether the OEL terms restrict hosting location or redistribution, and how licensing is priced and renewed.
The license question is not only about legal exposure. It also determines who ships fixes, who signs for security response and what happens to your roadmap when a feature sits behind a paid tier. Zitadel's model places most platform features, including organizations, SAML and SCIM, in the open source core under AGPL-3.0, with commercial terms available separately. Ory's model keeps the components open under Apache-2.0 but places several enterprise features and the support commitments in a commercial license. Both models can work for a regulated team, but the contract questions differ, and the reader should map each one to a named internal owner.
- Feature availability: Confirm which features you need, such as SAML, SCIM or multi-tenancy, and whether they are in the open source build or a paid edition.
- Security response: Compare the vendor's written CVE handling with your own patch cadence.
- Upgrade downtime: Ask whether upgrades can be done without downtime for your deployment model.
- Exit terms: Check how each license and contract treats continued use if you stop paying or change platforms.
- Audit evidence: Ask each vendor which license documents, notices and support records you can provide to auditors.
Before signing, have legal and procurement review the license text, the commercial terms and the support schedule together, and confirm them against the scope your team will run.
How each platform federates external identity providers
Both platforms can accept logins from an upstream identity provider, but they package that work differently. Zitadel ships provider connections as a built-in feature that you configure per organization, while Ory gives you the protocol engines and expects your team to assemble the connection flow around them. The cards below separate what is packaged from what you build, and where per-customer choice changes the design.
Zitadel's packaged upstream providers
Zitadel can federate login with Google, GitHub, GitLab, Apple, Entra ID and Okta over OIDC or SAML, plus LDAP and OpenLDAP, Keycloak, JWT identity providers and any OIDC-compliant provider. These are configured in the console rather than written as custom code. Check each provider's claim mapping and attribute handling against your own directory schema before you rely on it, because the packaged connector only saves effort if your attributes line up with what your applications expect. Packaged connectors reduce integration code, not design work.
Per-organization provider choice
In Zitadel, each customer organization inside an instance can use a different identity provider. This matters most for B2B products where one customer runs Entra ID, another runs Okta and a third needs an LDAP directory, and each tenant should manage its own login source. If all users sit behind one corporate identity provider, this feature adds little. Ask whether your tenants need separate upstream connections and whether your team will administer them or hand that work to customers.
Ory's protocol engines and social sign-in
Ory Kratos handles identities and social sign-in, while Ory Polis provides SAML and OIDC single sign-on with SCIM directory sync. Ory Kratos is API-first, so you build the login user interface and the routing that decides which provider a user sees. Social sign-in is part of the open source Kratos server, but SAML, SCIM and organization login are enterprise features under the Ory Enterprise License. Confirm with Ory which of these features your chosen edition includes before you design around them.
Directory federation: LDAP and Keycloak
Zitadel lists LDAP, OpenLDAP and Keycloak among its packaged upstream sources, so an existing directory or Keycloak realm can be connected without custom integration. Ory does not present a comparable packaged directory connector in the supplied material. If your users live in LDAP or Active Directory, you would need to confirm how Ory connects to them, either through Polis, through your own service or through a bridge, and who maintains that component after go-live.
Build effort on the Ory side
With Ory, each upstream connection is part of the application architecture. Your team owns the login flows, the mapping from external claims to Kratos identities, account linking when a user signs in through two providers, and the error handling when a provider is unavailable. Budget for this as design, build and testing work that recurs whenever a provider changes its protocol behavior. Ask any implementation partner to write the connection map and test cases in the statement of work before development begins.
Checks before choosing either path
Before you commit, list every upstream provider, the protocol each uses, and whether the connection is shared across the platform or specific to one customer. Test a provider's group or role claims, logout behavior and account deprovisioning, not only the first login. Confirm the Zitadel and Ory editions you plan to run cover the SAML, SCIM and organization features your federation design depends on.
What drives the running cost of each platform
Both platforms are Go services that keep their state in a relational database, so infrastructure cost starts with PostgreSQL and the application nodes that sit in front of it. Zitadel's documented self-hosting paths are a Linux binary, Docker Compose and Kubernetes with the official Helm chart, and Zitadel recommends Kubernetes with that chart for high availability. Ory splits its stack into separate services (Kratos, Hydra, Keto, Oathkeeper and Polis), so the number of deployed components depends on which ones your design needs. Costs in this tab are one-time for design and provisioning and recurring for compute, storage, backups and database licensing where your cloud or hosting provider charges for it.
- Database tier: Zitadel supports PostgreSQL 14 to 18 and Ory Kratos supports PostgreSQL, MySQL and CockroachDB. Ask which database engines your chosen components require and who operates the instance.
- Application nodes: Count the replicas needed for your availability target, then the load balancers and ingress in front of them.
- Backups and retention: Zitadel's event-sourced store keeps the change history, which affects storage growth over time. Ask how the vendor expects you to size event storage.
- Component count: Ory typically means running several services, each with its own configuration and scaling.
Ask the vendor or implementer to state the node count, database sizing assumptions and backup retention used in the quote.
Most of the recurring cost in an identity platform is people time: running upgrades, rotating keys, tuning the database and answering authentication incidents. Zitadel is a single Go service with a documented Kubernetes path, so the skills your platform team needs are Kubernetes, PostgreSQL and the Zitadel configuration model. Ory asks for the same platform skills plus integration work, because its components are headless and your team builds the login experience, the user management flows and the authorization logic around them. Staff cost is paid to your own employees or to an implementation partner, and it recurs for as long as the system runs.
- Platform skills: Kubernetes, PostgreSQL administration and TLS certificate management apply to both platforms.
- Application development: Ory's API-first design means your developers may build and maintain login and recovery screens, which is an ongoing cost.
- Go operations: Troubleshooting sometimes needs Go-aware logging and profiling. Confirm whether your team already has this capability.
- Vendor-specific knowledge: Each platform has its own configuration and event or API concepts that take time to learn.
Ask the implementer which tasks are included in the fixed scope and which are left to your staff after handover.
The license line is where the two platforms differ most. Ory's open source components are Apache-2.0, but SCIM, SAML, organization login (SSO) and CAPTCHAs are listed in the Kratos README as enterprise features not available in the open source version. The Ory Enterprise License (OEL) adds those features, Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. Zitadel's core, Console and hosted login are AGPL-3.0 since v3.0, and its APIs, SDKs and Helm charts remain Apache 2.0. Zitadel offers a commercial license for teams that cannot accept AGPL-3.0 terms. The OEL fee and the Zitadel commercial license fee are each set by the vendor, and neither figure is published in the sources used for this page.
- Ory Enterprise License: Recurring fee for enterprise features, support and CVE patch timing. Ask which components and features the quote covers.
- Zitadel commercial license: Needed only if AGPL-3.0 obligations are unacceptable. Ask whether it is per instance, per year or per user band.
- Open source paths: Ory open source and Zitadel's AGPL core carry no license fee but may lack features your design requires.
- Legal review: Counsel time to assess AGPL-3.0 obligations is a one-time cost that is easy to overlook.
Request the license fee, its term and renewal conditions in writing, and confirm which features each tier includes.
Ory states that Ory Open Source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Teams that need guaranteed patch timing typically look to the OEL or to a support arrangement. Zitadel publishes frequent releases, with v4.19.5 released on 15 October 2026, so upgrade planning is recurring work regardless of license. Upgrade effort includes testing the new version, applying database migrations, validating integrations with your applications and rolling out changes to every environment. Support cost is paid to the vendor or implementer, and upgrade labor is paid to your staff or a partner, both on a recurring basis.
- Support SLAs: The OEL includes 24/7 support SLAs. Open source paths generally do not, so compare the support windows you need against each option.
- CVE patch timing: Confirm the patch window, the severity levels covered and how patches reach you.
- Upgrade testing: Plan for regression tests against your own applications, especially where Ory's components are customized.
- Release cadence: Frequent releases raise the recurring effort of staying current.
Ask for the written support hours, response targets, patch commitments and upgrade assistance included in each option, and whether they are fixed or retainer-based.
Moving from Ory to Zitadel or from Zitadel to Ory
This sequence shows how a team moves identity from one stack to the other without a single cutover. It ends with both systems running in parallel, a tested login path for every relying party, and a written list of what was carried over and what was rebuilt.
Inventory identities, clients and login flows
The identity owner and the platform team list every user store, Kratos identity schema, Hydra OAuth2 client, Keto permission model, Oathkeeper rule and Polis SAML or SCIM connection, along with each relying application that depends on them. Zitadel's migration guides cover Auth0, Keycloak, Firebase and another Zitadel instance, so confirm whether your source is one of those or a custom Ory deployment that needs a bespoke export. The step is done when every client and flow has an owner and a target: migrate, rebuild or retire.
Export users and credentials where the format allows
Export identity records and password hashes from the source system, and confirm which credential types can move. Password hashes transfer only if the target accepts the hashing algorithm, so ask the Zitadel team or check its migration documentation before assuming a bulk import works. Passkeys, TOTP secrets and social links usually need the user to re-enroll. The output is a reconciled export with a count of records per type and a list of credentials that will require user action.
Plan just-in-time migration as the starting point
Zitadel documents just-in-time migration, where a user's record moves to the new instance at first login, as one of its migration approaches. This avoids forcing every account across at once and lets the old system stay authoritative for users who have not yet signed in. Decide with the security team whether the source remains reachable for verification during the transition, and document the cutover rule for accounts that never return. The step closes with a written migration design approved by the identity owner.
Rebuild flows, clients and permissions as Zitadel objects
Recreate Kratos login and recovery flows, Hydra clients and Keto permissions as Zitadel instances, organizations, projects, applications, roles and grants. Kratos flows are custom UI and do not map one to one onto Zitadel's hosted login, so expect rework on the login experience and confirm which branding and MFA policies Zitadel supports for your edition. Hydra clients become Zitadel applications with their redirect URIs and scopes. The check is a configuration review where each old client has a matching application and each Keto relation has a role or grant.
Re-point relying parties and test each login path
The application owners change issuer URLs, client IDs and secrets, and callback addresses in each relying party, then test sign-in, token refresh and logout against the new issuer. Include SAML and SCIM connections from Polis, which need separate metadata exchange and provisioning tests. Keep a rollback value for each application so a failed change can be reverted. The step closes when every relying party has passed a documented login test in a non-production environment.
Migrate sessions and MFA enrollments
Sessions do not transfer between the two systems, so plan for users to sign in once on the new platform. MFA enrollments such as TOTP and passkeys require re-registration unless the migration method carries them over, which should be confirmed in writing before any user communication. Schedule the user notice, the support runbook for re-enrollment and the process for identity verification when a user cannot complete enrollment. The output is a communication plan and a helpdesk procedure signed off by the service owner.
Run both systems in parallel and monitor
Keep the source and target running side by side, with traffic routed per application as each one passes its tests. Monitor failed logins, token errors, provisioning failures and helpdesk tickets on both platforms during the overlap. Event-sourced history in Zitadel does not map onto Ory's relational tables, so keep the source audit logs and retention records for the period your policy requires rather than expecting an equivalent history in the target. The step is done when all traffic is served by the target and the source has no active clients.
Retire the source and document the result
Disable the source identity services, revoke remaining credentials and archive the final export, configuration and audit records under the retention rules your compliance program requires. Record what transferred, what was rebuilt, what users re-enrolled and what was retired, so an auditor or future engineer can trace each identity path. The output is a signed migration record and an updated architecture diagram that names the new system as the authority for identity.
Where Zitadel and Ory implementation projects usually run long
Most long Zitadel and Ory projects are not slow because of the software. They run long because a few design decisions are made late, after integrations are already half built. For Zitadel, the groundwork is a PostgreSQL instance (versions 14 through 18 are supported for self-hosting), a deployment path chosen among the Linux binary, Docker Compose or the official Helm chart, and the instance and organization model. Decide early whether each customer gets its own organization inside one instance, and whether any customer needs stronger isolation through a separate instance, because moving users and projects later is expensive. Identity provider configuration for each customer (OIDC, SAML, LDAP or a federated Keycloak) is a separate workstream that multiplies with the number of tenants.
For Ory, the effort sits in assembly. A working deployment combines Kratos for identities, Hydra for OAuth 2.0 and OpenID Connect, Keto for permissions, Oathkeeper for the access proxy and, where SAML, SCIM or organization SSO is needed, Polis. Each service has its own configuration, database and upgrade cycle, and the team must build or adapt the login and consent UI that Ory leaves to you. Confirm with Ory which features you need and whether they sit in the Ory Enterprise License. The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features, and Kratos multi-tenancy and organizations are also in the OEL. Make that feature list a written decision before design starts, since it determines both licensing cost and what your team builds itself.
In both products, the items that most often extend the schedule are the tenant model, claim mapping between upstream identity providers and the tokens your applications expect, and cutover planning for moving existing users and passwords without a login outage. Ask any implementation partner for a written scope that names each identity provider, each application, the claim mapping rules, the migration method and the test cases for cutover and rollback. Effort estimates should be tied to that scope and to your own environment, and confirmed in writing before work starts.
Questions buyers ask before choosing Zitadel or Ory
What drives the cost of running Zitadel or Ory yourself?
The main cost is the people who plan, deploy, integrate and operate the stack, plus the infrastructure underneath it. For Zitadel, the self-hosted build needs a PostgreSQL database in every supported deployment mode, and the official Helm chart is the documented route to high availability on Kubernetes. For Ory, the open source components are split into separate services (Kratos, Hydra, Keto, Oathkeeper, Polis), so you own the integration work between them and the login UI you build on top. Recurring costs include upgrades, backups, monitoring and CVE response. Ask any quote to separate one-time build work from ongoing operations, and to state which Ory Enterprise License features, if any, are in scope and who pays for the license.
Can an in-house team run Zitadel or Ory without outside help?
Yes, many teams do, provided they already run PostgreSQL, containers or Kubernetes, and have engineers comfortable with OpenID Connect and OAuth 2.0. Zitadel gives you a single server with built-in organizations and a console, so the skills gap is mostly operational. Ory asks for more: you assemble several headless services, design your own account and login experience, and maintain the glue code. The honest test is whether your team can own upgrades, incident response and security patching on a fixed schedule. If not, a fixed-scope implementation or a retainer for support and upgrades is the usual alternative, and the written scope should say which parts your staff will own afterward.
How long does a typical Zitadel or Ory implementation take?
No duration is fixed by the platforms themselves, so the timeline depends on the work around them. The main drivers are the number of identity sources to federate (for example, Entra ID, Okta, LDAP or another Keycloak), whether you migrate existing users and how, the number of customer organizations or applications that need their own rules, and how much custom login UI you build. Ory usually adds design and integration time because the login experience and account flows are yours to build. Zitadel's migration guides and just-in-time migration can shorten the user move but still need testing. Ask for a timeline as part of the written, fixed scope, with milestones tied to each identity source and cutover step.
Do SAML and SCIM require a paid Ory license?
Yes, according to the Ory Kratos README, SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features not available in the open source version. Those features are offered through the Ory Enterprise License, which is a commercially supported self-hosted build of the same open source servers. Ory's own documentation describes the OEL as adding enterprise features such as Kratos multi-tenancy and organizations, plus 24/7 support SLAs and timely CVE patches. Ory's documentation also says open source suits evaluation, development and deployments that tolerate occasional upgrade downtime. Confirm the exact feature list, licensing terms and fees directly with Ory, because the terms can change. By contrast, Zitadel lists SAML 2.0 and SCIM v2 among the capabilities in its self-hosted core, under AGPL-3.0.
Does AGPL-3.0 affect an internal-only Zitadel deployment?
It depends on whether you modify Zitadel and how users reach it. AGPL-3.0 is a copyleft license, and its network clause can require source disclosure to users who interact with a modified version over a network. For a stock, unmodified Zitadel used only by your own staff inside your network, many legal teams find the obligations manageable, but that is a question for your counsel, not a conclusion to draw from this page. If you change Zitadel's core, Console or hosted login and expose it to outside users, the obligations become more likely to apply. Zitadel's APIs, SDKs, proto definitions, Helm charts and Terraform configurations remain Apache 2.0. Ask Zitadel for its commercial license terms if your legal review cannot accept AGPL-3.0.
What does the work need from our own staff?
Plan for a named owner on each side for identity architecture, infrastructure, security review and application integration. Your infrastructure team provides the PostgreSQL service or cluster, network paths, DNS, certificates, secrets storage and backup targets. Your identity team defines organizations or tenants, roles, identity sources and the claims each application needs. Your application teams handle redirect URIs, token validation and logout behavior. Your security team reviews configuration, MFA and passkey policy, and logging. For Ory, add the people who will build and maintain the login and account UI. Ask the quote to list these dependencies by name, so delays from missing access or decisions are visible early.
How do we get a fixed-scope quote for this work?
DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To make the quote comparable, bring the list of identity sources, applications and tenant or organization model, the number of users to migrate, your hosting target (Kubernetes, Docker Compose, Linux binary or a cloud or on-premises platform), your licensing constraints for AGPL-3.0 and the Ory Enterprise License, and the operating model you want after go-live. Ask for deliverables, acceptance criteria, what is excluded, and which retainer options cover upgrades and testing after handover.
Official sources to check before you decide
Zitadel and Ory publish different kinds of documentation: Zitadel's pages cover its license, database and tenant model in one product, while Ory splits its features across open source components, an enterprise license and a managed service. The cards below point to the pages where the claims in this comparison should be confirmed against current terms and your own requirements.
Zitadel licensing terms
Start with the LICENSING.md file in the Zitadel repository to see which parts of the codebase fall under AGPL-3.0 and which stay under Apache 2.0 or MIT. Confirm how the AGPL network clause applies to your planned use, including whether you modify Zitadel and expose it to users, and whether a commercial license is required for your organization. Ask your legal team to review this file before shortlisting.
Zitadel database requirements
The database page lists the PostgreSQL versions Zitadel supports for self-hosting. Confirm that your managed or on-premises PostgreSQL service is on a supported version, and check how the database is backed up, since Zitadel stores its event history there. Your database team should confirm the operational steps before you commit to a deployment pattern.
Zitadel organizations model
Read the organizations documentation to confirm how instances, organizations and projects map to your customers or business units. Check whether each organization can hold its own users, roles and identity provider settings, and whether your administrators need separate access to each tenant. This is the central design question for a multi-tenant B2B product.
Ory Enterprise License scope
The Ory Enterprise License page describes the paid self-hosted build and the features it adds, such as Kratos multi-tenancy and organizations. Confirm which features you need are included, what support and CVE patch commitments apply, and whether the build is a drop-in replacement for your current open source installation. Request the license terms in writing before you plan a migration.
Kratos enterprise feature boundary
The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features outside the open source build. If SAML or SCIM is a hard requirement, confirm the exact feature set in the README before treating open source Kratos as a fit. Note that Ory also pairs these features with Ory Polis, which is a separate repository you should review.
Ory pricing and managed options
The Ory pricing page sets out the managed Ory Network alongside self-hosted options. Compare what each tier includes against your hosting requirements, data residency rules and support expectations. Ask Ory to confirm any figures in a written quote, since pricing pages change and enterprise terms may differ from published tiers.
How DeployOpen helps choose, implement or migrate identity
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Zitadel or Ory decision, that means the work starts with the choice itself: which architecture the client's identity requirements actually call for, and which license terms the client's legal and procurement teams can accept. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen is not an official partner, reseller or certified provider of Zitadel, Ory or any other vendor, and it does not publish a price list. A quote follows from the written scope.
In practice, the first scoping questions are concrete. Does the team need organizations inside one Zitadel instance, or does it need Kratos multi-tenancy and organizations, which Ory lists as an Ory Enterprise License feature? Which of SAML, SCIM and Hydra's ROPC grant are required on day one? Where will the PostgreSQL database run, and which of the supported versions will the platform team operate? Each answer changes the build, the hardening work and the quote. DeployOpen can run this as a scoped assessment, then implement the platform the evidence supports, whether that is a Zitadel deployment using the Linux binary, Docker Compose or Kubernetes with the official Helm chart, or a headless Ory stack with a custom login UI. If the evidence points to a different platform, the assessment says so.
Migration carries its own scope. Moving users and applications from an existing identity provider needs a cutover plan, a rollback plan and a record of every decision for later audits. Zitadel documents migration guides from Keycloak and other sources, including just-in-time migration, and Ory's components are API-first, which means the team builds the login experience and data migration itself. Before signing, ask DeployOpen or any other implementer to confirm in writing the source systems, the identity provider integrations, the number of applications, the testing approach and the handover of documentation and runbooks. Also confirm who holds the license decision for the production environment, because the license terms, not the technology alone, may decide the outcome.
