Zitadel vs Logto: which to choose

Zitadel or Logto: when each one fits a B2B identity shortlist

If your product serves B2B customers who manage their own users, and the identity layer must run in your own infrastructure, the choice turns on two things. Zitadel fits teams that need multi-tenant instances with organizations, SAML, SCIM and an event-sourced audit history, and that can accept AGPL-3.0 for the core, Console and hosted login. Logto fits teams that prefer an MPL-2.0 Node.js stack, and that can either live with the self-hosted OSS limit of one administrator account or move administration to Logto Cloud, which includes team management.

The decision rests on four questions. First, is AGPL-3.0 acceptable for the components you would modify or expose to users, or does legal require a commercial license? Zitadel documents that a commercial license is available, and the license scope is set out in the vendor's LICENSING.md. Second, who administers the platform? Logto OSS by default supports only one admin account, so a team with several operators must confirm the self-hosted license terms or accept Logto Cloud. Third, who runs the database? Zitadel requires PostgreSQL 14 to 18 in self-hosted deployments, and Logto OSS requires PostgreSQL 14 or later with Node.js 22.14.0 or later.

Fourth, what does your engineering team already run? A Go shop will find Zitadel's operational model familiar, while a Node.js shop will find Logto easier to extend and debug. Before shortlisting either, confirm the SAML and SCIM requirements of your largest customers against each vendor's current documentation, and ask for a written quote from DeployOpen that reflects your chosen deployment model.

Which platform fits which scenario

This table maps common B2B identity scenarios to the platform that fits each one better, and the condition that drives the choice. Read each row as a starting point: confirm licensing terms for AGPL-3.0 (Zitadel) and MPL-2.0 (Logto) with counsel before committing, and test the admin and provisioning rows against your own environment.

Scenario	Better fit	Condition that drives the choice
Multi-tenant SaaS where each customer manages its own SSO	Zitadel	Organizations inside one instance, with each customer able to attach a different identity provider, match the model of customer-managed tenants. Confirm the isolation model you need against the instance and organization documentation.
Team that cannot accept AGPL-3.0 obligations	Logto	Logto's repository is MPL-2.0, a file-level copyleft license. Zitadel core is AGPL-3.0-only, so a commercial license would be needed. Confirm the obligations with counsel.
Node.js shop wanting a lighter operational footprint	Logto	Logto OSS runs on Node.js ^22.14.0 with PostgreSQL ^14.0, which fits a team already operating Node services. Zitadel is written in Go and runs on PostgreSQL 14 to 18, so it suits teams comfortable with Go-based services and an event-sourced store.
Many internal administrators on one self-hosted deployment	Zitadel	Logto OSS supports only one administrator account by default, and extra admin members need a self-hosted license. Confirm current admin role limits with the vendor before assuming Zitadel covers your admin model.
SCIM provisioning from an enterprise IdP into the platform	Zitadel	Zitadel provides a SCIM v2 service provider interface for standardized user provisioning and lifecycle management. Confirm Logto's SCIM coverage for your specific IdP before relying on it.
Audit history of every identity change over a long retention period	Zitadel	Zitadel's event sourcing stores each change as an event, which gives a built-in audit trail. Logto's audit behavior should be confirmed against your retention requirements.
Small internal deployment with a single admin and modest tenancy	Logto	Logto's single-admin default and Node.js footprint suit a small, lightly governed deployment. Confirm the production hosting guidance, since Logto advises against its bundled Docker Compose setup in production.

How Zitadel and Logto are built and deployed

Zitadel and Logto both target B2B products with multiple customer organizations, but they ask different things of your team. The cards below cover runtime, database, deployment paths and high availability, and what each choice means once the platform is running in your infrastructure.

Zitadel's event-sourced core

Zitadel is written in Go and stores every change as an event, which gives it a built-in audit trail of changes over an unlimited period. Tenancy is layered: instances are virtual tenants with full data isolation, organizations sit inside instances, and projects group applications, roles and grants. For day-two work, this means your backup and restore plan must cover the PostgreSQL event store, and you should confirm with the vendor how event history grows over your retention period. Self-hosted Zitadel supports PostgreSQL 14 to 18, so check that your database platform falls in that range before you commit.

Zitadel deployment paths

Zitadel documents three self-hosting routes: Linux binaries, Docker Compose and Kubernetes. Each one needs a PostgreSQL instance, so the database is never optional. The vendor recommends a Kubernetes cluster with the official Helm chart for high availability. Choose the path your team can operate for years, not only the one that installs fastest, and ask DeployOpen or the vendor to confirm how upgrades, init jobs and image tags are handled in that path.

Zitadel high availability guidance

The vendor's recommended high availability setup is Kubernetes with the official Helm chart. Running the server on a single host works for evaluation, but production resilience depends on how you run PostgreSQL, failover and backups, which are your responsibility under self-hosting. Ask for a written statement of what the vendor supports for multi-node operation, and test failover against your own database topology before go-live rather than relying on the diagram.

Logto's Node.js runtime

Self-hosted Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0. Your platform team therefore needs a supported Node.js lane in its patching cycle, alongside the database. Logto's own Node.js version requirement is a moving target across releases, so check it against the release you plan to deploy and again before each upgrade. Teams already running Node services will find this familiar; teams that standardized on Go or JVM tooling may need a new runtime owner.

Logto sizing and hardware floor

The Logto docs recommend at least 2 vCPU, 8 GiB of memory and 256 GiB of disk for self-hosted OSS. Treat these as a starting floor, not a capacity plan. Load, tenant count, log retention and database growth will push the real numbers up. Ask Logto or your implementation partner for sizing guidance that matches your expected login volume and number of organizations, and budget the disk for database growth.

Logto Docker Compose warning

Logto's docs warn against using its Docker Compose command in production because it bundles a Postgres database that is recreated on each run. That means a routine restart can wipe your data. For production, the documented alternative is running the official image with docker run against a database you manage. Build your backup, restore and database hosting plan before you touch the container definition, and confirm the Compose path is used only for evaluation.

How the tenant model and identity integration differ

Zitadel separates tenancy into three levels: an instance is a virtual tenant with full data isolation, organizations sit inside an instance and hold users, and projects group applications, roles and grants. Logto lists multi-tenancy, enterprise SSO and RBAC, with organizations that support organization RBAC, member invitations and just-in-time provisioning. The gap matters most when each customer needs hard data separation or its own administrators. Confirm with Logto how its tenants map to data separation in your deployment model before you assume an equivalent boundary.

Isolation boundary: Zitadel's instance is the strongest documented separation, while Logto's multi-tenancy boundary needs a test in your own environment.
Customer self-management: Zitadel's organizations suit products where each customer administers its own users, as described in the Zitadel organizations documentation.
Application and role grouping: Zitadel keeps applications, roles and grants inside projects, which affects how you model access for each customer.
Console administrators: Logto OSS supports one administrator account by default, and more admin members need a self-hosted license, so plan the console access model early.
Migration fit: Confirm how each platform represents your existing tenant structure before you commit to a data model.

Ask each vendor to demonstrate, in a test environment, that an administrator for one customer cannot read another customer's users or applications.

Capability comparison from supplied facts

This table sets Zitadel and Logto side by side on license, release, database, tenant model, protocols, provisioning, admin limits and cloud options. Where a row says to confirm, the fact was not established for that platform, so ask the vendor before you rely on it. The main takeaway is that Zitadel publishes more of the B2B identity features you may need, while Logto's self-hosted admin limits and missing SCIM detail need verification.

Capability	Zitadel	Logto
License	AGPL-3.0 for core, Console and hosted login; APIs, SDKs and Helm charts under Apache 2.0	MPL-2.0 for the repository
Current release	v4.19.5, released 15 October 2026	v1.45.0, released 13 October 2026
Database and runtime	PostgreSQL 14 to 18 for self-hosting	Node.js ^22.14.0 and PostgreSQL ^14.0 for self-hosted OSS
Tenant model	Instances with full data isolation, organizations, then projects, applications and roles	Multi-tenancy with organizations, organization RBAC and just-in-time provisioning; confirm isolation model
Protocols and SCIM	OIDC, OAuth 2.0, SAML 2.0 and SCIM v2 provisioning interface	OIDC, OAuth 2.1 and SAML; confirm SCIM support with Logto
Passkeys and device grant	Passkeys (FIDO2 and WebAuthn) with password fallback; device authorization grant	Not established in supplied facts; confirm passkey and device grant support
Migration tooling	Guides for Auth0, Keycloak, Firebase and Zitadel, including just-in-time migration	Not established in supplied facts; confirm import and migration paths
Self-hosted admin model	Event-sourced change history; confirm admin role limits and audit depth with Zitadel	One admin account by default in OSS; more admins need a self-hosted license
Cloud option	Zitadel Cloud alongside self-hosting; check current plan limits on the pricing page	Logto Cloud is fully managed and includes team management; Logto recommends it for official support

What each license and edition means for your organization

Since Zitadel v3.0 (31 March 2025), the core, Console and hosted login are licensed under AGPL-3.0. The Zitadel blog explains that APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0. Your obligations depend on whether you modify the software and how users reach it, so the deployment pattern matters as much as the license name.

Core services: the identity server, Console and hosted login fall under AGPL-3.0 from v3.0 onward. Releases before that date were under Apache 2.0, so older documentation may describe different terms.
Network use: AGPL-3.0 applies when users interact with a modified version over a network. If you change Zitadel code and serve it to customers through a branded login page, plan to make those changes available to those users.
Integration code: the Apache 2.0 APIs and SDKs do not by themselves extend AGPL-3.0 to your own applications that call them.
Infrastructure code: Helm charts and Terraform configurations stay under Apache 2.0, which makes reuse in your own pipelines simpler.

Have counsel confirm whether your planned customer-facing login and any internal modifications create source-offer duties before go-live.

Why Zitadel's event-sourced audit trail changes operations

Zitadel stores every change as an event, so its audit trail is a property of the data model rather than a logging feature bolted on afterward. According to the Zitadel event store documentation, this gives a built-in record of all changes over an unlimited period. For a B2B identity platform where customer administrators create organizations, grant roles and change identity providers, that history is the record an investigator will ask for first. The practical consequence is that the event store, not a separate log pipeline, becomes the thing you size, back up and retain.

That changes operations in three ways. Storage grows with the history of changes rather than only with current users, so the team should model event volume against its tenant count and administrative activity before going live. Backup planning must cover the PostgreSQL database that holds the event store, since self-hosted Zitadel uses PostgreSQL 14 to 18 and the audit history is only as durable as that database. Investigations become queries against events over time, which shortens the path from question to answer, but only if the team agrees on who may read that history and how long it is kept.

Logto uses a more conventional data model. Before choosing either platform for a regulated tenant model, confirm in your own environment how Logto records administrative and user activity, where those records are stored, how long they persist, and whether they can be exported to your SIEM. Ask the same questions of Zitadel, because an event store only meets an audit requirement if the retention and access rules around it are written down. If your compliance program requires a specific audit control, map that control to the evidence each platform actually produces, and treat any gap as a scope item for the implementation partner to close.

What drives the running cost of each platform

Running cost for Zitadel and Logto comes from the same few places: the database and hosting layout, the people who operate the stack, the support model, the upgrade cadence and the edition terms. Both platforms are self-hostable, but the bill differs by who pays for each component. Use the cards below to build the list of questions you send to each vendor before comparing quotes.

Database and high availability layout

Both platforms depend on PostgreSQL in production. Self-hosted Zitadel supports PostgreSQL 14 through 18, and self-hosted Logto OSS requires PostgreSQL ^14.0. Your cost follows from the database service you choose, its backup and failover design, and the number of nodes you run. Zitadel recommends Kubernetes with the official Helm chart for high availability, so ask what that layout means for your team. For Logto, the docs warn against the Docker Compose setup in production because it bundles a database that is recreated on each run. Confirm how each vendor's documented layout maps to the database service you already operate.

Runtime and operating skills

Zitadel is written in Go and ships as a binary, container or Helm deployment. Logto OSS runs on Node.js and needs a Node.js runtime version within the range the vendor documents. Your staff cost depends on which runtime your platform team already patches, monitors and debugs. A team that runs Go services will read Zitadel's logs and upgrade path differently from a team that runs Node.js services. Ask each vendor which runtime versions they test against and how long you should expect to spend on runtime updates each year.

Support model and managed option

Logto's docs recommend Logto Cloud for official support rather than self-hosting on third-party providers, so a self-hosted Logto deployment may rely on community support and your own engineers. Zitadel offers a commercial license and enterprise contracts for self-hosting, which the vendor describes on its pricing page. Ask each vendor what support covers in a self-hosted setup, what response commitments apply, and whether support is priced per instance, per user or per contract. DeployOpen can plan and run the deployment under a fixed-scope agreement, but support terms come from the vendor.

Upgrade cadence and release effort

Release frequency affects your running cost because each upgrade needs testing, database migration checks and a rollback plan. Logto published v1.43.0 on August 31, v1.44.0 on September 30 and v1.45.0 on October 13, 2026, which is a monthly-style rhythm. Zitadel published v4.19.5 on October 15, 2026. Count the releases your team must absorb in a year, then ask each vendor which versions receive security fixes and for how long. Plan the test environment and maintenance window as recurring costs, not one-time setup.

Edition and admin seat terms

Licensing decides which costs are fixed and which grow with use. Self-hosted Logto OSS supports only one administrator account by default, and adding more admin members requires a self-hosted license, while Logto Cloud includes team management. Zitadel is licensed under AGPL-3.0 for its core, with a commercial license offered for teams that cannot accept AGPL terms. Ask Logto for the admin seat price and whether it scales with users or staff. Ask Zitadel what the commercial license covers, whether it includes support, and how it is priced.

Implementation and migration effort

The one-time cost is often larger than the recurring fee. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, including just-in-time migration. Logto's organization model, SAML and SCIM setup and enterprise SSO connectors each add configuration work for B2B tenants. Ask each vendor which migration path applies to your current identity provider, what data it moves, and what remains manual. A fixed-scope implementation quote from DeployOpen should list each of these items with its acceptance criteria.

Moving from Logto to Zitadel or back: what transfers and what is rebuilt

This sequence sorts what can move between Logto and Zitadel from what has to be rebuilt, so the cutover happens with a tested fallback. The output is a signed-off migration map and a rollback plan that the platform team can run.

Inventory tenants, organizations, applications and identity providers
The platform owner lists every tenant or organization in the source Logto deployment, along with the applications registered under each, the identity providers each organization uses, and the roles and permissions attached to them. Logto's organization model and Zitadel's model of instances, organizations, projects and grants do not map one to one, so write down where each Logto object would land in Zitadel before any data moves. Done when a table exists that links every Logto organization and application to a planned Zitadel instance, organization, project or grant, and the security owner has reviewed it.
Confirm which user data and password hashes can move
The identity engineer checks what Logto exports for users, profile fields, custom data, MFA enrollments and password hashes, and what Zitadel can import without forcing a password reset. Zitadel's published migration guides cover Auth0, Keycloak, Firebase and another Zitadel instance, but the public material supplied for this page does not document a Logto path, so confirm the approach directly with Zitadel and with Logto's export options before assuming any hash format is compatible. Done when the team has written confirmation of the supported path, and a list of fields that will be rebuilt, reset or re-enrolled.
Choose the migration approach for users
The team picks between a bulk export and import, a just-in-time migration where Zitadel checks credentials against the old system at first login, or a mix of both for different user groups. Just-in-time migration is one of the approaches Zitadel documents for its other migration paths, so ask Zitadel whether it can be applied to a Logto source in your case. Cost and effort depend on the chosen path, the number of users and the amount of custom logic, so ask the implementation partner for a written estimate that names each piece of work. Done when the approach is approved for each user group and the risks of password resets or MFA re-enrollment are documented.
Rebuild client registrations and redirect URIs
The application owners recreate each OIDC client in Zitadel, with its redirect URIs, post-logout URIs, scopes, token settings and client authentication method copied from the Logto configuration. Logto applications are not moved as-is, so every redirect URI must be re-entered and tested against the new issuer. Keep the Logto client IDs in the migration map so that dependent services can be switched in a known order. Done when each application completes a login, token refresh and logout test in a staging Zitadel instance.
Recreate identity provider connections and roles
The identity engineer rebuilds each upstream connection, such as SAML or OIDC federation to a corporate provider, inside the matching Zitadel organization, and maps roles and grants to the projects that use them. Each customer organization can use its own identity provider in Zitadel, so test each connection with a real user from that organization before cutover. Confirm SCIM provisioning requirements separately, since Zitadel offers a SCIM v2 interface and any directory feeding Logto today must be pointed at the new endpoint. Done when each identity provider completes a test login and each role grants the expected access in staging.
Run a staged pilot with a small user group
The operations team moves a limited set of low-risk applications and users to Zitadel while Logto stays live, then monitors sign-in success, token errors, MFA prompts and support tickets. Keep both platforms reachable from the same network path so that a single application can be pointed back to Logto without a wider change. Done when the pilot group has run through a full business cycle with an agreed error threshold and every defect is closed or accepted in writing.
Plan cutover and rollback
The change owner writes a cutover runbook for each application, listing the DNS or configuration change, the freeze window, the user communication, the check that closes the change and the exact steps to point the application back to Logto. Rollback must include a decision point, who can call it, and what happens to users who signed in to Zitadel during the window, including whether their changes need to be replayed into Logto. Done when the runbook has been rehearsed in staging, and the sponsor has approved both the cutover and the rollback path.
Retire the source platform after verification
Once every application runs on the target platform and the rollback window has closed, the team disables Logto sign-in, archives its database and configuration exports under the agreed retention policy, and removes stale client registrations and secrets. Keep the migration map and test records as evidence for internal audit or the compliance assessment. Done when a signed record shows that no application still points to Logto, all exports are stored in the approved location, and the access logs confirm no active use.

Where Zitadel and Logto implementation projects usually run long

Zitadel projects usually run long in the database and deployment design, and in onboarding customer identity providers. Self-hosted Zitadel needs a PostgreSQL instance in every deployment method, and the supported versions are 14 through 18. Teams often spend their early weeks deciding how that database is provisioned, backed up and made highly available, and whether the Linux binary, Docker Compose or the official Helm chart on Kubernetes fits their operating model. Zitadel recommends Kubernetes with the Helm chart for high availability, so a team that starts on Compose and later moves will need a migration plan. The longer tail is per-organization identity provider onboarding. Each customer organization can use its own identity provider, so each one becomes a separate configuration, test and sign-in check. Confirm with the vendor how many organizations and providers are in scope before a fixed-scope plan is written.

Logto projects usually run long in the Node.js and PostgreSQL runtime setup and in the admin model decisions. Self-hosted Logto OSS requires Node.js ^22.14.0 and PostgreSQL ^14.0, and the getting started documentation advises against its Docker Compose file in production because that file bundles a Postgres database that is recreated on each run. Production work therefore means choosing and hardening an external database, running the official image with docker run or an equivalent, and setting up backups. The admin model is the decision that is hardest to reverse. By default self-hosted Logto OSS supports only one administrator account, and additional admin members need a self-hosted license, while Logto Cloud includes team management. SAML and SCIM integration testing with each enterprise customer's identity provider then tends to take the most cycles. Under a fixed-scope agreement, DeployOpen would plan, implement, harden, back up and document these items, with the deliverables and acceptance tests written down before work starts.

Questions buyers ask before choosing Zitadel or Logto

What does a self-hosted Zitadel or Logto rollout cost, and what drives it?

No price can be given from the researched facts, so the cost depends on the written scope. Software licensing is only part of it: the open-source core of each platform is free to download, but the engagement cost comes from the people who design, deploy, integrate and operate the system. The main drivers are the number of applications and identity sources to connect, whether SAML and SCIM provisioning are needed for each customer organization, the database and high availability design, the migration of existing users, and the level of support you want after go-live. Recurring costs include infrastructure, database operations, upgrades and any vendor subscription. Ask any provider for a quote that separates one-time implementation from recurring support, and ask Zitadel or Logto to confirm which paid licenses or plans your use case requires.

How long does a self-hosted identity rollout take?

No duration is given here because it depends on scope, and any figure without a defined scope would be misleading. The schedule is driven by how many customer organizations need their own identity provider federation, how many applications must be integrated with OIDC, SAML or SCIM, whether existing users must be migrated from another system, and how much of the database, Kubernetes or Node.js platform work is new to your team. A fixed-scope plan lists these items, the deliverables and the timeline in writing before work starts. Ask for the timeline as a function of the listed scope, and treat any duration that does not reference specific integrations and migrations as a starting point, not a commitment.

What skills must our team have to run Zitadel or Logto?

Both platforms need a PostgreSQL database, so your team needs someone who can operate PostgreSQL 14 or later, including backups, restores, upgrades and capacity planning. Zitadel's documented high availability path uses Kubernetes with the official Helm chart, so Kubernetes skills matter if you choose that route. Self-hosted Logto OSS requires Node.js ^22.14.0, so a team that already runs Node.js services will find the runtime familiar, while Logto's documentation advises against its Docker Compose setup for production. Identity architecture skills are needed for either platform: tenant and organization design, federation with customer identity providers, role and grant models, and token configuration. Ask DeployOpen or any other provider which of these skills are already in-house, and plan training or support for the gaps.

Can our team run Zitadel or Logto without an implementation partner?

Yes, a capable internal team can run either platform without a partner, but it should first confirm the skills and capacity it has for the scope it needs. The tasks that most often need outside help are the initial architecture of tenants and organizations, the integration of each customer's identity provider, the migration of existing accounts, and the hardening and backup design. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed-scope agreement, with ongoing support available as a retainer. Whether you build internally, hire a partner for part of the work, or engage for the full scope depends on your team's experience and on how much of the operating burden you want to carry.

Does AGPL-3.0 or MPL-2.0 licensing limit how we can use Zitadel or Logto?

The license determines what you must disclose when you modify and offer the software over a network, so it should be reviewed by your legal team before adoption. Zitadel's core, Console and hosted login moved from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, and its APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations remain Apache 2.0. The AGPL includes a network clause, so organizations that modify Zitadel's core and provide it to users over a network should review their obligations, and Zitadel offers a commercial license for teams that cannot accept AGPL terms. Logto's repository is licensed under MPL-2.0, a file-level copyleft license that typically requires you to share changes to MPL-covered files, not your whole application. Confirm with each vendor which parts of its product are covered by which license, and whether paid editions carry separate terms.

How do we compare SAML and SCIM support between Zitadel and Logto?

Start by listing the exact SAML and SCIM behavior your customers and applications require, then test both platforms against that list rather than relying on feature summaries. Zitadel documents SAML 2.0 support and a SCIM v2 service provider interface for standardized user provisioning and lifecycle management, and it can federate login with SAML or OIDC identity providers per customer organization. Logto states full support for OpenID Connect, OAuth 2.1 and SAML, with enterprise SSO and organizations that support just-in-time provisioning. Check whether SCIM is inbound provisioning from your customers' identity providers, outbound provisioning to your applications, or both, and which attributes and group behaviors each platform supports. Build a proof of concept with a representative customer identity provider, and ask both vendors to confirm the features on your list in writing.

What should we ask a vendor about admin limits and editions before we commit?

Ask about the number of administrator accounts, team management and the features that depend on a paid tier, because these change how your operators can work. The researched facts state that self-hosted Logto OSS supports only one administrator account by default, and that adding more admin members requires a self-hosted license, while Logto Cloud includes team management. Zitadel publishes Free and Pro plan details for its cloud service and Enterprise contracts for cloud and self-hosting, so review its pricing page and ask which features and limits apply to your intended deployment. Confirm whether administrator roles, audit needs and multi-operator workflows are included in the edition you select, and record the answers in the quote so the scope is clear.

Official sources to check before deciding

Start with the licensing question, because it can decide the shortlist before any feature comparison matters. The Zitadel blog post on the move from Apache to AGPL explains which parts of Zitadel moved to AGPL-3.0 with v3.0 on 31 March 2025 and which stayed under Apache 2.0, including the APIs, SDKs, proto definitions and Helm charts. Have your legal or procurement team read it against your internal rules on network-facing AGPL-3.0 software, and confirm with Zitadel how the commercial license applies to your deployment. Logto's repository is MPL-2.0, so the two licenses carry different obligations on modifications and hosting, and that difference belongs in the same review.

Next, check the operational footprint against your own platform standards. The Zitadel database documentation lists PostgreSQL 14 through 18 as supported, and the Zitadel self-hosting overview covers the Linux binary, Docker Compose and Kubernetes options. For Logto, the Logto OSS getting started guide sets Node.js ^22.14.0 and PostgreSQL ^14.0 as requirements, warns against using its Docker Compose file in production, and states that the default self-hosted edition supports only one administrator account. Ask each vendor for a written statement of which tier you need for your admin model before you commit to a design.

Finally, verify the B2B tenant model against your own customer structure. Read the Zitadel organizations documentation and the Zitadel SCIM v2 guide to confirm how instances, organizations and projects map to your customers and how provisioning reaches each one. Then compare Logto's organization model in the logto-io/logto repository, checking how it handles SAML, SCIM and just-in-time provisioning per organization. Run a proof of concept with one real customer scenario and record what each platform required.

How DeployOpen helps choose, implement or migrate identity

DeployOpen works on Zitadel vs Logto as a self-hosted implementation inside your own cloud accounts, data centers or air-gapped networks. We start from the written scope, so the choice between the two platforms is tested against your tenant model, identity sources and admin requirements before anything is built.

How we scope

Agree in writing which tenant model your customers need, whether organizations, instances or both.
Confirm which SAML and SCIM flows, identity providers and user sources the engagement must cover.
Record the self-hosting target, database version and admin account needs before a quote is issued.

How we build

Deploy the chosen platform with PostgreSQL in your environment, using the database versions the vendor documents.
Configure organizations, applications, SAML and SCIM connections, and federated identity providers to the agreed scope.
Test login, provisioning and admin workflows against the written acceptance criteria before go-live.

How we hand over

Deliver runbooks covering installation, configuration, backups, upgrades and admin procedures for your team.
Document the decisions behind the platform choice, including licensing and admin limits your team must review.
Provide the evidence and configuration records your auditors or compliance leads ask for during assessments.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Plan version upgrades against each vendor's release cadence, with changes agreed in writing first.
Ask your DeployOpen contact to confirm retainer coverage for your environment before the handover closes.

Zitadel vs Logto