Which open-source CIAM platform fits your product and team
If your SaaS or app must authenticate its own customers, and many of those customers want their own single sign-on, start with the product model. Zitadel fits multi-tenant B2B products because organizations inside one instance let each customer manage its own users, and it ships a hosted login. Ory fits teams that want headless APIs and plan to build their own login screens on Ory Kratos and Ory Hydra. Logto fits teams that want an MPL-2.0 core with a managed option through Logto Cloud. Keycloak and Casdoor are worth knowing for context: Keycloak is the widely deployed Apache-2.0 server covered in the access management comparisons, and Casdoor is outside the scope of this page.
Two license points change the shortlist. Zitadel's core, console and hosted login moved from Apache 2.0 to AGPL-3.0 with Zitadel v3 on March 31, 2025, while its APIs, SDKs and Helm charts remain Apache 2.0. Confirm with your legal team whether AGPL obligations fit how you distribute or host the software. In Ory, SCIM, SAML, organization login (SSO) and CAPTCHAs are described in the Kratos README as enterprise features not available in the open source version, so a B2B SSO requirement may point you to the Ory Enterprise License or Ory Network rather than to the open source build alone.
Before you commit, write down three answers: whether each customer needs its own identity provider, whether your team wants to own the login interface, and whether you can accept AGPL terms for the identity core. Then ask each vendor which features in your list are included in the edition you would run, and which need a paid license. Those answers usually settle the choice faster than feature matrices.
Which CIAM option fits which scenario
This table maps common customer identity scenarios to the platform that fits best, with the condition that would change the choice. Read each row as a starting point for your shortlist, then confirm the named features against current documentation and your own requirements before you commit.
| Scenario | Best fit | Why, and when the choice changes |
|---|---|---|
| B2B SaaS where each customer brings its own identity provider | Zitadel | Organizations inside one instance let each customer use a different identity provider, and SAML, OIDC and SCIM are documented. The choice changes if your license posture cannot accept AGPL-3.0 for the core, in which case compare Ory or Logto. |
| Headless build where your team owns the login UI | Ory (Kratos and Hydra) | Kratos is API-first and Hydra works through headless APIs, so your team builds every screen. The choice changes if you need SCIM, SAML or organization SSO in production, which the Ory Kratos README lists as enterprise features. |
| Small app that needs a fast start with a managed fallback | Logto | Logto offers OIDC, OAuth 2.1 and SAML with a managed Logto Cloud option for official support. The choice changes if you must run a multi-admin self-hosted deployment, since the open source edition supports one administrator by default. |
| Broad federation across many legacy and enterprise systems | Keycloak | Keycloak brokers logins to external OIDC or SAML providers and federates users from LDAP or Active Directory under Apache-2.0. The choice changes if you need per-customer tenant isolation at SaaS scale, where Zitadel's organization model is a closer fit. |
| Regulated team that needs a documented audit trail of identity changes | Zitadel | Zitadel's event sourcing stores every change as an event, which supports audit review. Confirm retention settings and export options in your own environment before relying on them for evidence. |
| Team that already runs Active Directory for workforce users | Keycloak or Logto (illustrative) | Both can connect to directory or enterprise identity sources, but confirm the exact federation and sync behavior for your directory version. The choice changes if the workload is purely workforce, where a directory service may be the better home. |
How tenant models differ across Zitadel, Ory and Logto
Zitadel gives the clearest tenant model of the three for B2B products. A self-hosted Zitadel deployment is organized as instances, which are virtual tenants with full data isolation, and organizations sit inside an instance and hold the projects and users. An organization is comparable to a tenant in a SaaS system, and several organizations can run inside one instance, which suits products whose customers want to manage their own users. Each customer organization can also point to its own identity provider, so one customer's SSO setup does not have to be shared with another. Check whether your isolation requirement is met by a separate instance per customer, which gives full data isolation, or by organizations inside one shared instance, which is operationally lighter but shares the instance itself.
Logto takes a different route. It lists multi-tenancy, enterprise SSO and RBAC as features, and its organizations support organization RBAC, member invitations and just-in-time provisioning, so a customer's users can be created on first sign-in. This fits teams that want organization-level roles without running several instances. Ory handles tenancy differently: Ory Kratos multi-tenancy and organizations, along with SCIM, SAML and organization login, are enterprise features in the Ory Enterprise License rather than the Apache-2.0 open source build. Ory Hydra stays a headless OAuth 2.0 and OpenID Connect server that your own application or user model sits behind, so tenant boundaries are enforced by the code you write. Before you shortlist any of them, ask each vendor in writing how tenant data is separated at the database, key and admin-console level, and test a cross-tenant access attempt in a non-production environment.
Hosted login versus headless APIs: what each option gives your team
Zitadel pairs a hosted login with its APIs, so your team can send users to sign-in screens that the Zitadel instance serves while your applications handle sessions and tokens. Most of the work sits in configuring the instance, organizations, projects and identity providers, not in building sign-in pages from scratch. That shifts login UX ownership toward your platform team and away from your front-end team, although the exact branding and flow controls depend on the release you deploy.
- Login screens: Zitadel serves the hosted login, so flow order and screen behavior follow its maintained pages. Confirm which branding and flow settings your target release exposes before promising a custom look.
- Passkeys: Passwordless login uses passkeys based on FIDO2 and WebAuthn, with fallback to password login.
- Federation: Login can federate with Google, GitHub, GitLab, Apple, Entra ID, Okta, LDAP, OpenLDAP, Keycloak and any OIDC-compliant provider, and each customer organization can use a different identity provider.
- Provisioning: A SCIM v2 service provider interface covers standardized user provisioning and lifecycle changes.
- License scope: Since v3.0, the core, Console and hosted login are AGPL-3.0, while APIs and SDKs stay Apache 2.0. Ask counsel how AGPL applies if you modify the hosted login itself (Zitadel blog on the license change).
Before you commit, check whether your branding and MFA requirements fit the hosted screens in your target release.
Logto is grouped with hosted login approaches in this comparison, so your team gets a sign-in layer and admin console that handle authentication flows for SaaS applications. Logto describes itself as open-source auth infrastructure for SaaS and AI apps under MPL-2.0. Its strongest fit is B2B SaaS that needs organizations, enterprise SSO and role-based access, with the login experience largely provided by the platform. Confirm in the current documentation how far each sign-in screen can be restyled and which steps can be reordered.
- Login screens: Logto supplies the sign-in experience and admin console. Confirm which screens can be replaced or restyled in the version you plan to run.
- Protocols: Logto states full support for OpenID Connect, OAuth 2.1 and SAML.
- Organizations: Organization RBAC, member invitations and just-in-time provisioning are listed for multi-tenant products.
- Self-hosting prerequisites: Self-hosted OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0, with a recommended 2 vCPU, 8 GiB of memory and 256 GiB of disk.
- Admin accounts: Self-hosted OSS supports one administrator by default, and more admin members need a self-hosted license. Logto Cloud includes team management.
The vendor recommends Logto Cloud for official support, so ask whether your self-hosted model needs a license for team administration and how the official support boundary applies to your deployment.
Ory takes the headless route: Kratos manages identities through APIs, Hydra issues OAuth 2.0 and OpenID Connect tokens, and your team builds the login UI. Hydra is an OpenID Certified server that works with an existing user management system through headless APIs, so it does not provide the sign-in pages itself. You own the login experience and the code that drives each flow, which gives full design control but moves the build and security work to your team.
- Login UX ownership: Kratos is API-first, so your application defines screens, error handling and step-up prompts. Plan for design, accessibility and testing of every flow.
- Database support: Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Confirm which database and high availability pattern your operations team will run.
- Enterprise gating: The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features not in the open source version. Ory Polis, which is Apache-2.0, covers SAML and OIDC single sign-on with SCIM directory sync.
- Support model: The Ory Enterprise License adds optimized builds, enterprise features, 24/7 support SLAs and timely CVE patches. Ory says open source suits evaluation and deployments that accept occasional upgrade downtime and do not require guaranteed CVE patching.
- Managed option: Ory Network is the vendor's managed cloud service, offered alongside the self-hosted components.
Before you choose this route, confirm the enterprise features you need and whether open source meets your patching expectations.
Authentication factors are where hosted and headless options differ most in day-to-day effort. Hosted platforms ship factor flows that the vendor maintains, while headless platforms let you choose each factor and build its enrollment, recovery and fallback behavior. The supplied facts cover these factors unevenly across the options, so treat each claim below as a starting point for your own proof of concept.
- Zitadel: Passkeys based on FIDO2 and WebAuthn are supported, with fallback to password login. Federation to social and enterprise providers is supported. Confirm the MFA methods available in your target release.
- Ory Kratos: Passwords, passwordless codes, passkeys, social sign-in and multi-factor authentication such as TOTP are supported, and your team builds the screens for each.
- Logto: Full protocol support and enterprise SSO are listed, but this comparison has no supplied fact on passkeys, MFA methods or social connectors. Confirm them in the current documentation.
- Ory Hydra: Hydra handles tokens, not login, so passkeys, MFA and social sign-in come from the user management system you connect to it.
- Recovery and enrollment: Account recovery and factor reset are where most support tickets come from. Ask each vendor how these flows are configured and who operates them.
Before you commit, test passkey enrollment on the devices and browsers your users run, and confirm the MFA and social providers you need.
The cost of this decision is mostly in labor. Hosted platforms shift routine flow work to configuration, upgrades and vendor maintenance, while headless platforms add build, testing and security review for every login path your product needs. Both models have one-time setup and recurring operations, and the recurring part includes upgrades, patch handling and monitoring. Your quote should separate design, integration, hardening and ongoing support so you can compare the two models on equal terms.
- Hosted model: Your team configures the platform, connects identity providers and tests the integration. The vendor's flows carry much of the sign-in logic, so review its release notes for each upgrade.
- Headless model: Your team or implementation partner builds screens, session handling, recovery, verification and abuse controls. Those flows need threat modeling and penetration testing before launch.
- Enterprise features: Confirm whether SSO, SCIM or multi-tenancy require a license in the edition you run, because that changes the recurring cost.
- Patch responsibility: Ask who applies CVE patches, how fast, and who tests them in your environment.
- Fixed scope: DeployOpen agrees scope, deliverables and timelines in writing before work starts, and ongoing support is offered as a retainer.
When you request a quote, ask each option for the flows in scope, the license tier required, and the upgrade and patch process.
Capability table across Keycloak, Zitadel, Ory, Logto and Casdoor
This table compares Zitadel, Ory and Logto on license, release, database, tenant model, protocols, provisioning, federation, passkeys, migration and managed options, with Keycloak included for context (Apache-2.0, relational database required in production). No researched facts were supplied for Casdoor, so every Casdoor claim must be confirmed with its vendor, and blank Logto cells need the same check. Treat each cell as the starting point for a vendor question, and expect Zitadel and Ory to offer the most documented detail on multi-tenancy and SCIM.
| Capability | Zitadel | Ory | Logto |
|---|---|---|---|
| License | AGPL-3.0-only core (OSI-approved); a commercial license is also offered and is not open source. APIs and SDKs stay Apache 2.0. | Kratos, Hydra, Keto, Oathkeeper and Polis are Apache-2.0. The Ory Enterprise License is a separate commercial license. | Repository is MPL-2.0. Confirm which enterprise features need a self-hosted license with the vendor. |
| Current release | v4.19.5, released 15 October 2026. | Kratos and Hydra v26.2.0, both published 20 March 2026. | v1.45.0, published 13 October 2026. |
| Database | PostgreSQL 14 to 18 for self-hosted deployments. | Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Confirm Hydra database support. | PostgreSQL 14 or later, with Node.js 22.14 or later for self-hosted OSS. |
| Tenant model | Instances with full data isolation, organizations inside instances, and projects for apps and roles. | Kratos multi-tenancy and organizations are Enterprise License features. | Multi-tenancy and organizations with organization RBAC and member invitations. |
| Protocols (OIDC, OAuth, SAML) | OpenID Connect, OAuth 2.0 and SAML 2.0, plus a device authorization grant. | Hydra is an OpenID Certified OAuth 2.0 and OIDC server. SAML and SSO sit in Polis. | Full support for OpenID Connect, OAuth 2.1 and SAML, per the vendor README. |
| SCIM provisioning | SCIM v2 service provider interface for standardized provisioning. | SCIM directory sync comes through Polis. Kratos lists SCIM as an enterprise feature. | Confirm SCIM support and scope with the vendor. |
| LDAP, AD and brokering | Federates from LDAP and OpenLDAP. Brokers Google, GitHub, Entra ID, Okta, Keycloak and any OIDC or SAML provider per organization. | Confirm LDAP, AD and upstream connector coverage for your deployment. | Enterprise SSO is listed. Confirm LDAP, AD and connector list with the vendor. |
| Passkeys and migration | Passkeys based on FIDO2 and WebAuthn with password fallback. Migration guides from Auth0, Keycloak and Firebase. | Kratos supports passkeys and TOTP. Confirm migration tooling with the vendor. | Confirm passkey and migration support with the vendor. |
| Managed option | Zitadel publishes a pricing page. Confirm managed hosting terms with the vendor. | Ory Network is the managed service, offered alongside self-hosted components. | Logto Cloud is the managed service, which the docs recommend for official support. |
Each option in brief, with its license
Each card gives the license, latest supplied release, database and main trade-off for one option. Zitadel, Ory and Logto are the three self-hosted CIAM candidates, and Keycloak and Casdoor are included for context. Check the license terms and the feature split between open source and paid editions before you shortlist any of them.
Zitadel: AGPL-3.0 multi-tenant identity
Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 in March 2025. APIs, SDKs, Helm charts and Terraform configurations stay Apache 2.0. The latest supplied release is v4.19.5, published October 15, 2026, and self-hosted instances use PostgreSQL 14 to 18. Its instance, organization and project model suits B2B products where each customer manages its own users. Have counsel review the AGPL obligations before you modify the core or offer it to users over a network.
Ory: Apache-2.0 headless stack
Ory Kratos (identities), Hydra (OAuth 2.0 and OpenID Connect), Keto (permissions), Oathkeeper (access proxy) and Polis (SAML, OIDC and SCIM sync) are each Apache-2.0. Kratos and Hydra v26.2.0 were both published March 20, 2026. Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Its README lists SCIM, SAML, organization SSO and CAPTCHAs as enterprise features absent from the open source version, and you build your own login UI, so confirm which of these features you need before choosing the open source path.
Ory Enterprise License and Ory Network
The Ory Enterprise License is a self-hosted, commercially supported build of the same open source servers. It adds features such as Kratos multi-tenancy and organizations and the Hydra ROPC grant, along with 24/7 support SLAs and timely CVE patches. Ory states that OEL builds are a drop-in replacement for open source installations. Ory Network is the managed cloud service offered alongside both. Ask what the license covers, which SLA applies, and whether your data stays in your own infrastructure.
Logto: OSS admin and runtime limits
Logto's repository is MPL-2.0. It supports OpenID Connect, OAuth 2.1 and SAML, with organizations and just-in-time provisioning. The latest supplied release is v1.45.0, published October 13, 2026. Self-hosted OSS needs Node.js ^22.14.0 and PostgreSQL ^14.0. By default, self-hosted OSS allows only one administrator account, and more admin members require a self-hosted license, while Logto Cloud includes team management. The Docker Compose file bundles a Postgres database that is recreated on each run, so do not use it in production.
Keycloak: the Apache-2.0 baseline
Keycloak is Apache-2.0 and is the reference point most CIAM evaluations start from. Keycloak 26.8.1, released October 13, 2026, is the current release. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external providers, and federates users from LDAP or Active Directory. Production needs a relational database such as PostgreSQL 14 to 18. Check how its realm model maps to your customer isolation requirements before you compare it with the multi-tenant options.
Casdoor: context only
Casdoor is included here for context as an open-source identity option for application login. This page does not supply verified facts on its license, latest release, database or paid features, so confirm each of these directly with the project before shortlisting it. Ask whether it covers the SAML, SCIM and per-customer organization features your B2B customers need, and test its admin and upgrade process in your own environment.
Licensing and editions: what is free, what is paid
Start with the license, because it decides what you can run without a contract. 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. Its APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0, so client code and deployment tooling can keep their original terms. The AGPL applies to the server itself, and a commercial license is available from the vendor. If your product modifies the Zitadel server and offers it to users over a network, ask counsel to review the AGPL obligations before launch and ask Zitadel for the commercial license terms in writing. Read the Zitadel blog post on the move from Apache to AGPL before you rely on this split.
Ory divides its stack in a different way. Kratos, Hydra, Keto, Oathkeeper and Polis are each Apache-2.0, but the Ory Enterprise License (OEL) adds optimized builds with enterprise features such as Kratos multi-tenancy and organizations, SCIM, SAML, organization SSO and CAPTCHAs, plus 24/7 support SLAs and timely CVE patches. Ory states that open source suits evaluation, development and deployments where occasional upgrade downtime and unpatched CVEs are acceptable. If you need SAML or SCIM for enterprise customers, or a documented patch commitment for regulated workloads, budget for the OEL from the start. Ask Ory which features are in the OEL build you would receive, and what the CVE patch and support commitments are, in the order form.
Logto publishes its core under MPL-2.0, which permits commercial self-hosting without a license fee for the open source edition. The limit to plan for is administration: by default, self-hosted Logto OSS supports only one administrator account, and adding more admin members requires a self-hosted license. Logto Cloud includes team management instead. Confirm the number of administrators your operations and support teams need, and get the self-hosted license terms, price basis and renewal conditions in writing before you choose Logto for a team-based deployment. Whatever the vendor, paid edition terms should cover what is included, support response commitments, upgrade and patch support, and what happens to your deployment if you stop paying.
How to choose and pilot a CIAM platform
This sequence moves a team from a tenancy decision to a working pilot, so the shortlist of Zitadel, Ory and Logto is tested against real customer flows before any commitment. Each step produces a written output that the next one depends on.
Define the tenancy model first
Product and architecture leads decide whether the platform serves one application with one user population or many B2B customers who each manage their own users. Zitadel organizes tenants as instances, organizations and projects, and its documentation describes organizations as the comparable unit to a SaaS tenant, so a B2B product needs that structure mapped on paper. Logto lists multi-tenancy and organizations as well, so ask each vendor how its model maps to your customer boundaries. The output is a one-page tenancy diagram that names what a customer, an organization and an application are in your product.
Choose hosted login or headless APIs
The engineering lead decides whether the team wants a hosted login page that the platform renders, or APIs that let the team build its own login user interface. Ory Kratos is API-first and lets teams build their own login UI, while Zitadel and Logto provide hosted login flows alongside their APIs. Record which screens your product must control, such as branded sign-up, progressive profiling or step-up prompts, and whether your front-end team will own them. The output is a signed decision that names the login surface and the team that maintains it.
List required protocols and provisioning
The security architect writes the list of protocols each application and customer needs, including OpenID Connect, OAuth 2.0, SAML 2.0 and SCIM. Check each candidate's documentation for the exact feature, because Ory states that SCIM and SAML for Kratos sit in its enterprise features and Logto states SAML support in its README. Zitadel documents SCIM v2 for provisioning and federation with many upstream providers. The output is a requirements table with a column for each candidate and a source link or test result for every cell.
Check license fit and support rules
Legal, procurement and the security lead compare each license against how your organization distributes software and what support it must buy. Zitadel moved its core, Console and hosted login to AGPL-3.0 with v3, while its APIs and SDKs remain Apache 2.0, which matters if you ship client code or run modified hosted pages. Ory's open source components are Apache-2.0, but the Ory Enterprise License covers multi-tenancy, organizations and CVE patch commitments, and Logto's repository is MPL-2.0 with paid self-hosted admin seats. The output is a written license memo that lists which features are open source and which require a paid license or subscription.
Confirm database and hosting prerequisites
The platform engineering lead checks that the database versions and the runtime each candidate needs can run in your environment. Self-hosted Zitadel supports PostgreSQL 14 to 18, and Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0, with a recommended 2 vCPU, 8 GiB of memory and 256 GiB of disk. Logto also warns against its Docker Compose file in production, so confirm the deployment method with the vendor before building. Ory Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. The output is a short environment sheet that matches each candidate to your approved database and compute platform.
Run a migration test from your identity store
The engineering team exports a sample of users from the current identity store, which may be a directory, another identity provider or an older platform, and imports them into each shortlisted candidate. Zitadel documents migration guides, including just-in-time migration, which avoids moving every password up front. Confirm how each candidate handles password hashes, MFA enrollment and user identifiers before the test starts. The output is a migration log that records imported users, failed records, login success for a sample of accounts and the manual steps required.
Pilot with one customer organization
The product team selects one real customer organization that already manages its own identity provider and configures it to federate with the candidate platform. Zitadel documents that each customer organization can use a different identity provider, which is the behavior to test, and Logto documents just-in-time provisioning for organizations. Include an administrator from that customer in the test, and verify sign-in, role assignment, deprovisioning and the audit trail of changes. The output is a signed pilot report that states which platform passed each test, with open issues assigned to an owner.
Decide with the pilot evidence
The steering group compares the pilot report, the license memo and the migration log against the requirements table and selects one platform or drops the shortlist. The decision record names the accepted license terms, the database and hosting prerequisites, the paid features needed and the support model, whether self-hosted or managed. Ask each vendor or implementation partner for a written quote based on this scope, since pricing depends on the confirmed feature set. The output is a decision record that the team can hand to procurement and to the auditors who review access controls.
Questions buyers ask before choosing a self-hosted CIAM platform
What drives the cost of self-hosting a customer identity platform?
Infrastructure, the database, upgrades, support subscriptions and any paid edition you need are the main drivers, and each is paid to a different party. Infrastructure and database hosting are recurring costs in your own cloud account or data center. Logto OSS, for example, recommends at least 2 vCPU, 8 GiB of memory and 256 GiB of disk, and requires PostgreSQL ^14.0, so sizing and database operations are a real line item. Licensing varies: Zitadel's core is under AGPL-3.0-only with a commercial license offered, and Ory's SCIM, SAML and organization SSO features are enterprise features. Ask any vendor or partner for a quote that separates one-time setup from recurring infrastructure, upgrades, CVE patching, and subscriptions, and state which paid editions each line assumes.
How long does a CIAM pilot take to scope, and is the timeline agreed in writing?
The timeline depends on scope, which is set by the number of applications, identity providers to federate, user stores to migrate and compliance evidence required. DeployOpen works mostly on fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope. No general duration figure is given here. Ask for a written statement of scope, the milestones that mark completion, the environments included, and what happens if a dependency such as an identity provider integration is delayed. Vendor migration guides, such as Zitadel's guides for Keycloak and Auth0, help you judge how much migration work is in scope.
What does the work need from our internal team?
Your team needs to own decisions that only your organization can make, even when an implementation partner does the build. These include the tenant model, which customer accounts map to organizations or instances, the identity providers your enterprise customers use, password and passkey policy, session lengths, and who approves production changes. Engineers need working knowledge of OpenID Connect, OAuth 2.0 and SAML, and someone must own the database backups and the upgrade calendar. Ask the partner which decisions it expects you to make, when, and who signs off on them, and write that responsibility matrix into the statement of work.
Can a small team run a self-hosted CIAM platform on its own?
A small team can run one if it has operations and identity skills and accepts the upgrade and patch workload. Self-hosted options differ in how much they depend on paid tiers. Ory states that Ory Open Source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Logto OSS supports only one administrator account by default, and Logto's documentation recommends Logto Cloud for official support rather than self-hosting on third-party providers. Keycloak needs a relational database in production, and the Keycloak Operator is installed through the Operator Lifecycle Manager or kubectl. Before deciding, list who will take the on-call pager, how security patches reach production, and whether the team can test upgrades before applying them.
When does a managed service such as Zitadel Cloud or Logto Cloud change the calculation?
A managed service changes the calculation when the cost of operating the platform, including patching, backups, uptime and upgrade testing, exceeds the value of keeping data in your own infrastructure. Zitadel publishes pricing on its pricing page, and Logto Cloud is the vendor's fully managed service that includes team management. Ory Network is its managed cloud service, offered alongside the self-hosted components and the Ory Enterprise License. Self-hosting remains the right choice when data residency rules, air-gapped networks or contractual terms require it. Compare the managed plan's data location, support windows and exit terms with a self-hosted quote, and check the tenant and feature limits of each plan before comparing prices.
Which parts of a CIAM rollout create the most risk during migration?
Migrating existing users, sessions and credentials causes most of the risk, along with the cutover from an old login flow. Zitadel documents migration approaches such as just-in-time migration from Auth0, Keycloak and Firebase, and just-in-time approaches let users move as they sign in rather than in one batch. Password hashes may not transfer cleanly between systems, so test with real hash formats before cutover. Plan a rollback path for each application, confirm token lifetimes and redirect URIs, and run both systems in parallel for a defined period. Ask the implementer to document each cutover step and the rollback procedure in writing.
What should a compliance team ask for before accepting a CIAM design?
Ask for evidence that the platform's controls can be configured, tested and recorded, not for a claim that it is certified. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Zitadel's event sourcing model stores every change as an event, which gives a built-in audit trail, and its self-hosted deployment supports PostgreSQL 14 to 18. Ask for a mapping from each control your auditor cares about to a configuration, log source or retention setting, and ask who holds the logs and for how long.
What running each platform in your environment takes
Start with the deployment path your platform team already runs, because it decides most of the day-two work. Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends a Kubernetes cluster with the official Helm chart for high availability. It needs PostgreSQL 14 through 18. Keycloak in production needs a relational database (PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database or Amazon Aurora PostgreSQL), and on Kubernetes or OpenShift its Operator installs through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. Confirm which of those database engines your DBA team will support before you pick a topology, since that choice sets your backup and upgrade routine.
Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0, and its docs recommend at least 2 vCPU, 8 GiB of memory and 256 GiB of disk. Logto's getting-started docs also warn against using its Docker Compose command in production, because that file bundles a Postgres database that is recreated on each run. Use the official image with docker run against your own managed PostgreSQL instead, and check the sizing against your expected login volume with the vendor before you commit to a host profile. Note that the default self-hosted edition supports only one administrator account, so plan admin access and team management before rollout.
Ory is not one server but a set of components (Kratos for identities, Hydra for OAuth 2.0 and OpenID Connect, Keto for permissions, Oathkeeper as a proxy and Polis for SSO), and each has its own configuration, database and upgrade path. Kratos is API-first, so your team builds the login UI, registration, recovery and MFA flows itself, and that frontend becomes a product you own and test. Before you estimate effort, ask Ory which components a self-hosted design requires for your use case, and budget for the front-end and flow work as well as the infrastructure. Whichever platform you pick, ask the vendor or implementation partner for the upgrade, backup and restore runbook in writing before go-live.
How DeployOpen scopes and delivers a CIAM selection and implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For customer identity, that means turning the choice between Zitadel, Ory, Logto and the other options into a written scope tied to your tenant model, login flows and compliance evidence needs.
How we scope
- Confirm the tenant model first: instances, organizations or workspaces, and which customers manage their own users.
- Record which login pattern you need, hosted login or headless APIs, and which front end teams own it.
- Agree in writing which federation sources, SAML and SCIM connections, and MFA methods are in scope.
How we build
- Deploy the chosen platform into your cloud account, data center or air-gapped network, using the database versions it supports.
- Configure identity provider connections, provisioning and roles, then test each customer login path end to end.
- Harden the deployment, set up backups and document upgrade steps against the vendor's current release line.
How we hand over
- Deliver architecture, configuration and runbook documents written for your platform and security teams.
- Walk your administrators through tenant creation, user onboarding and recovery procedures before handover.
- Prepare the access, logging and change records that your auditor or certification body will ask to see.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the fixed-scope work ends.
- Plan upgrades around each vendor's published release and license terms, and confirm them before each change.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
