Keycloak vs Zitadel multi-tenancy: which model fits your B2B product
Choose Zitadel when each customer needs a hard boundary and the customer's own administrators will manage their users. Zitadel models tenants as instances, which it describes as virtual tenants with full data isolation. Inside an instance, organizations hold the users and projects for each customer, and each customer organization can use a different identity provider. Choose Keycloak when you run one identity estate for your own product, need SAML and LDAP or Active Directory federation alongside OpenID Connect, and can confirm that its realm model and Organizations feature cover your customer delegation needs.
The conditions decide the winner. For isolation strictness, Zitadel's instance boundary is the clearest separation in either product, so regulated customers who require separate data stores usually point toward instances. For Keycloak, confirm whether one realm per customer or a shared realm with Organizations fits your isolation requirement, and how many realms your administrators can operate. For customer self-administration, check in a pilot what a customer administrator can change in Keycloak Organizations without your console access, including members and identity provider settings, because the feature's current scope should be confirmed in the Keycloak server administration guide for your release.
For per-customer identity providers, Keycloak brokers logins to external OpenID Connect or SAML providers and federates LDAP or Active Directory, but confirm whether each organization can hold its own broker configuration in your target release. Zitadel lists per-organization identity providers as a supported pattern, which fits customers who bring Entra ID, Okta or an LDAP directory. Before you request a quote, ask for a proof that creates two customer tenants, delegates administration to a test customer administrator, and provisions one federated login per tenant. Scope that proof in writing, since tenant automation and migration work drive most of the effort.
How each platform models tenants, side by side
This table compares how Keycloak and Zitadel model tenants across seven parts of a B2B product, from the tenant unit to the self-hosting footprint. Read each Keycloak cell alongside the Organizations confirmation items, because the supplied facts do not settle how Organizations behave in every release. The main takeaway is that Zitadel names a tenant layer in its model, while Keycloak's tenant boundary depends on how you combine realms and Organizations.
| Aspect | Keycloak | Zitadel |
|---|---|---|
| Tenant unit | Realm is the main isolation unit; confirm how Organizations group customers inside a realm | Instance is a virtual tenant; organizations sit inside each instance |
| Isolation boundary | Realm holds its own users, clients and settings; confirm what Organizations share | Instance gives full data isolation between tenants |
| Where users and projects live | Users sit in the realm; confirm which objects an Organization can own | Users and projects live in organizations; projects group apps, roles and grants |
| Per-customer identity providers | Brokers logins to external OIDC or SAML providers; confirm per-Organization binding | Each customer organization can use a different identity provider, including OIDC, SAML and LDAP |
| Customer admin delegation | Confirm whether customers can manage their own members and providers without realm admin rights | Suits B2B products whose customers manage their own users; confirm role and grant scope |
| Database and audit trail | Production needs a supported database such as PostgreSQL 14 to 18; confirm admin event retention | Event sourcing stores every change, giving a built-in audit trail over an unlimited period |
| Self-hosting footprint | Relational database required; Operator on Kubernetes, or server distribution on virtual machines | Binaries, Docker Compose or Kubernetes; Helm chart recommended for high availability |
How Keycloak realms and Organizations map to B2B tenants
In Keycloak, the realm is the boundary that matters most for multi-tenancy. A realm is the administrative and user-store unit: it holds its own users, clients, roles, identity brokering settings and admin permissions, and it is isolated from other realms. A realm-per-tenant model therefore gives each customer its own login pages, its own identity provider configuration and its own administrators, at the cost of running and upgrading many realms. The alternative is one shared realm for all customers, with customer structure modeled inside it. Keycloak's Organizations feature is the in-realm construct for that second approach, but the supplied facts do not describe how it behaves, so do not assume its behavior from the realm model. Check in the Keycloak server administration guide which objects Organizations can hold, whether users can belong to more than one organization, how each organization is linked to its own identity provider, and which admin permissions can be delegated per organization.
The trade-off comes down to isolation and operating load. Realm-per-tenant gives the cleanest data and configuration boundary, and it lets a customer's administrators work inside a realm that cannot see other customers. It also multiplies configuration: every realm needs its own clients, mappers and brokering setup, and every change must be repeated or automated across them. A shared realm keeps one set of clients and one upgrade path, but a misconfigured organization or role can affect more tenants, so the reader should test cross-tenant access before go-live. For either model, write down the delegation rules, test that a customer administrator cannot see another customer's users or clients, and confirm with the vendor how Organizations is licensed and supported in the release you plan to run.
Per-customer identity providers and how each handles them
Customers who bring a cloud workforce directory usually want sign-in against their existing Entra ID or Okta tenant, with no separate password stored in your product. Zitadel documents Entra ID and Okta among the upstream providers it can federate over OIDC or SAML, and each customer organization can use a different identity provider. Keycloak brokers logins to external OIDC or SAML providers, so the protocol match exists on both sides. The differences appear in how each customer's setup is created, administered and tested.
- Protocol coverage: Both platforms support OIDC and SAML upstream, so the protocol alone rarely decides the choice for this group.
- Per-organization binding: Zitadel's documentation supports a different provider per customer organization. For Keycloak, confirm whether a broker can be bound to one customer's organization inside the Organizations feature in the release you plan to run, or whether each customer needs its own realm or broker.
- Provisioning: Zitadel provides a SCIM v2 service provider interface for user lifecycle changes. Confirm whether your customers need SCIM push from Entra ID or Okta and whether Keycloak covers that flow in your build.
- Claim and group mapping: Mapping directory groups to application roles is where most rework happens. Test each customer's group structure with a sample tenant before go-live.
Before committing, ask each platform to demonstrate a second customer's Entra ID or Okta connection alongside the first, and confirm where the per-customer configuration is stored and who can change it.
Customers whose users sit in an on-premises LDAP directory or OpenLDAP create a different operating pattern. The directory holds the passwords and group membership, and the identity server either reads from it or connects to it. Keycloak federates users from LDAP or Active Directory, so it treats the directory as a user store. Zitadel lists LDAP and OpenLDAP among its supported identity provider options. Both can serve this group, but they differ in where accounts live, how group changes reach the application and what network access each deployment needs.
- Read direction: Keycloak's LDAP federation reads users from the directory. Confirm whether you need changes made in the application to be written back to LDAP, since that changes the service account permissions you grant.
- Multiple directories: Many customers means many federation or identity provider configurations. Confirm how each platform stores and isolates per-customer directory settings and how admin effort grows as the count rises.
- Connectivity: Customer directories often sit behind firewalls or VPNs. Confirm the bind account, TLS requirements and the behavior when a directory is unreachable, including whether existing sessions keep working.
- Nested groups: Test how each platform resolves nested groups in each customer's directory, because role mapping errors often come from group nesting rather than from authentication itself.
Ask each customer for a read-only service account and a test directory, then confirm with both platforms how a failed bind is reported to the customer's administrators.
Some customers already run their own Keycloak realm or issue JWTs from a service they control. In that case, the customer's system is the upstream identity provider and your platform trusts its tokens. Zitadel lists Keycloak and JWT identity providers among its options. Keycloak can broker to an external OIDC provider, so a customer's Keycloak realm fits the same pattern. JWT is a token format rather than a complete login flow, so the trust model needs more explicit design: which issuer is trusted, which keys verify signatures and how a token becomes a user.
- Keycloak as upstream: Confirm which realm, client settings and scopes the customer must provide, and whether the customer or your team manages them after go-live.
- JWT trust configuration: For JWT providers, confirm how Zitadel validates the issuer, signing keys and token expiry, and how the user is matched or created on first sign-in.
- Key rotation: Confirm how each platform handles a signing key rotation at the customer's issuer and whether a rotation requires a manual change on your side.
- Outage behavior: Confirm what happens when the upstream issuer is unavailable and which team is alerted.
Before go-live, document with each customer which party owns the trust configuration, the key rotation process and the contact path for an incident at their issuer.
What changes the multi-tenancy result in practice
Keycloak and Zitadel both can serve B2B customers, but the right model depends on how strictly tenants must be isolated, who administers users, and how the platform is licensed and run. The cards below name the condition under which each factor starts to decide the outcome.
Isolation strictness in customer contracts
If a customer contract requires full data isolation, check whether a shared realm with organization membership meets that clause or whether each customer needs its own tenant boundary. Zitadel instances are described as virtual tenants with full data isolation, while Keycloak realms are the isolation unit for identity data. Ask legal and security to map the contract wording to a specific boundary before design starts, and confirm with the vendor how each product's isolation claim applies to your deployment.
Customers administering their own users
If your customers' administrators must create accounts, reset passwords and manage roles without your staff, delegation rights decide the design. Zitadel organizations are described as suited to B2B products whose customers manage their own users. Confirm in Keycloak how far the Organizations feature and admin roles go for your use case, and test the exact delegation scenario before you commit to either model.
Number of tenants and rate of change
A small, stable set of large enterprise tenants can run comfortably under a different structure than thousands of self-service tenants that appear and disappear each week. Under high churn, measure how often onboarding and offboarding touch the identity store, and whether tenant creation is an API call your automation can drive. Ask each vendor for documented limits on tenant counts in your target configuration.
Per-customer identity provider needs
When each customer brings its own corporate IdP, the number of connections and their maintenance becomes the main operating load. Zitadel documents that each customer organization can use a different identity provider. For Keycloak, confirm how many brokered identity providers one realm or organization can hold and how they are configured, and check whether your onboarding flow can create them without manual console work.
License obligations and hosting choices
Keycloak is Apache-2.0, while Zitadel moved its core, Console and hosted login to AGPL-3.0 with v3. If you modify the server or run it as a network service for customers, the AGPL-3.0 network-use terms may apply to your modified code, which can affect how you host and what source you must share. Have counsel review the license text against your planned architecture before choosing the platform.
Database operating model
Both products store identity data in PostgreSQL in production, and Keycloak also supports MariaDB, MySQL, Microsoft SQL Server, Oracle and Amazon Aurora PostgreSQL. Zitadel's event store keeps every change as an event, which adds storage growth and an audit trail to plan for. Decide which database your team already operates and backs up, then size retention and high availability with the vendor's guidance for your tenant volume.
How to test tenant isolation and delegation in your environment
This sequence gives you a short proof of concept that checks whether Keycloak or Zitadel keeps each customer's users, identity providers, tokens and audit records separate, and whether a customer administrator can act only inside their own tenant. The output is a written pass or fail result for each check, which you can take into scoping and procurement.
Define two sample tenants and their scope
Your architect and a product owner agree on two illustrative customer tenants, for example Tenant A and Tenant B, each with a named customer administrator and a few test users. Write down which applications each tenant will sign in to and which roles each user needs. Map this onto the candidate models: Keycloak realms or its Organizations feature, and Zitadel instances and organizations. The step is done when both tenants are described in a one-page test plan that the security and product leads have signed off.
Configure a separate identity provider per tenant
The identity engineer connects a different external identity provider to each tenant, using a test directory or a test OIDC or SAML provider for each. For Zitadel, confirm that each organization can use its own identity provider. For Keycloak, confirm whether the chosen design uses a realm per tenant, an Organizations setup, or a broker configuration, and record which option was used. The step is done when a user from Tenant A can sign in only through Tenant A's provider and a user from Tenant B cannot reach Tenant A's login path.
Test customer admin delegation boundaries
Sign in as the customer administrator of Tenant A and attempt to create, disable and reset users in Tenant A, then attempt the same actions against Tenant B's users, applications and roles. Repeat with an administrator who holds only an application-level role. Log each attempt with the expected result before running it. The step is done when every action inside the tenant succeeds, every action outside it is refused, and the results are attached to the test plan.
Verify token and cross-tenant data boundaries
Obtain tokens for a Tenant A user and decode them to check issuer, audience, organization or realm claims and roles. Present a Tenant A token to a Tenant B application and to the admin API for Tenant B, and confirm rejection. Compare user lists and search results across tenants with the admin account of each. The step is done when no token from one tenant is accepted for another tenant's resources and no list shows records outside its own tenant.
Check audit trail visibility per tenant
Perform a set of known changes in each tenant, such as creating a user, changing a role and removing a provider link. Then check what the customer administrator can see in the logs and what the platform operator sees. Confirm where events are stored and how long they are retained, and ask the vendor to confirm how Zitadel's event-sourced history and Keycloak's event and admin logs are filtered by tenant. The step is done when each known change appears in the expected log, and you have a written answer on what each role can view.
Measure the steps to provision a new tenant
Have an operator who has not built the test environment create a third illustrative tenant from the written runbook for each candidate. Record every manual step, every screen or API call, and every point where a value had to be copied between systems. Note which steps could be scripted, such as through the Keycloak Operator custom resources or Zitadel's APIs. The step is done when you have a step count and a list of manual actions for each platform, which you can use to ask vendors and implementation partners for a fixed-scope quote.
Document results and confirm open questions
Collect the pass or fail results, the runbook changes and the open questions into one report for the architecture review. Mark each unresolved item with the person who will confirm it, such as the vendor, your auditor or your own platform team. Include the production database and high availability choices that the test environment did not cover. The step is done when the report has a decision for each tenant check and a named owner for every open item.
What tenant models cost to build and change later
The licence line is the smallest cost in either tenant model. Keycloak and Zitadel can both be downloaded and run without a licence fee, but the spend shows up elsewhere: the database and its high availability, the infrastructure underneath it, the people who run upgrades, and the integration work that makes each customer's login behave. Zitadel also offers a commercial license alongside its AGPL-3.0 core, and Keycloak can be taken as Red Hat's supported distribution, so a written quote should state which of those, if any, is included. Ask the vendor or partner to price each separately and to say which one is needed for your deployment model.
Most of the one-time cost is design and integration. With Keycloak, that means deciding whether each customer gets its own realm or a shared realm with the Organizations feature, then building the client, role and identity brokering configuration for each tenant. With Zitadel, it means choosing how instances, organizations and projects map to your customers, then configuring per-organization identity providers. Recurring cost is operations: database upgrades, schema migrations, certificate rotation, and reviewing delegated admin access. Effort rises fastest with customer-specific identity providers, realm sprawl in Keycloak, and any migration between tenant models after customers are live, because user identifiers, sessions and provisioned accounts all have to move. Ask for the effort to add the tenth customer, not only the first, and for the rate at which new identity providers are expected to be onboarded.
Ask any quote to list the following as separate line items: discovery and tenant model design, identity provider integration per customer type, admin delegation setup, the target database and its high availability design, a migration plan with rollback steps, testing for tenant isolation, and the upgrade process for each platform version. Confirm which items are one-time and which are retainer based, and who owns the customer-facing identity provider configuration after handover. Also confirm with the vendor how each platform's supported upgrade path and any licence terms apply to your planned edition, because those terms can change the recurring cost more than the initial build does.
Questions buyers ask about multi-tenant identity
Can Keycloak serve many B2B customers in one realm?
Keycloak can host many customers, but the realm is the unit that holds users, clients and identity provider settings, so a single shared realm needs careful design. Many teams either separate customers into their own realms or evaluate the Organizations feature first. Confirm in the current Keycloak server administration guide how Organizations scope membership, login behavior and admin rights before you commit. The main drivers are the number of customers, whether each customer needs its own login policy or identity provider, and how many clients each tenant brings. Build a proof of concept with two or three representative tenants and check that one customer's configuration cannot affect another's.
Do we need a separate Zitadel instance for each customer?
No. In Zitadel an organization is comparable to a tenant in a SaaS system, and multiple organizations can be managed within one instance, which suits B2B products whose customers manage their own users. An instance is the stronger boundary, since it is a virtual tenant with full data isolation. Use separate instances when a customer needs its own data isolation, its own configuration baseline or a stricter separation for contractual or regulatory reasons. The drivers are isolation requirements, the number of customers and how much operational overhead your team accepts, because every instance is one more configuration to maintain. Read the Zitadel organizations documentation before deciding where to draw the line.
How much work do per-customer identity providers add to a B2B platform?
The per-customer work is mostly configuration and testing, and it grows with the number of customers and how different their identity providers are. Zitadel documents that each customer organization can use a different identity provider, and it federates over OIDC, SAML, LDAP and other sources such as Entra ID and Okta. Keycloak brokers logins to external OIDC or SAML providers. Each connection typically needs metadata exchange, redirect URI registration, claim or attribute mapping, certificate rotation planning and a login test with the customer's own administrator. Ask any implementation partner for a quote that lists these tasks per identity provider and states who maintains each one after go-live.
Can customers manage their own users on Keycloak and Zitadel?
Zitadel's model supports this directly: organizations are where users live, and projects, roles and grants are scoped within them. Keycloak's answer depends on how you structure realms or Organizations and which admin roles you delegate, so confirm in the Keycloak administration documentation exactly what a delegated admin can view and change. For provisioning from a customer's own directory, Zitadel provides a SCIM v2 service for standardized user lifecycle management. Test the model before you promise it: a customer administrator should be able to create a user and assign a role, and should be unable to see or change any other customer's users. Document that test as acceptance criteria.
What does it cost to move customer tenants to another platform later?
The cost is one-time for the move but can be large if the tenant model is hard to change. Zitadel documents migration guides from Keycloak and describes approaches such as just-in-time migration, which moves a user record when that user first signs in. The cost drivers are the number of users, how password hashes and MFA enrollments are carried over, whether passkeys must be re-registered, redirect URI changes in every client, and how many customer identity providers must be reconfigured. Running two platforms in parallel adds cost for the overlap period. Ask for a quote that includes a cutover plan, a tenant-by-tenant order and a rollback path. Review the Zitadel migration guides as a starting point.
Can our team run Keycloak or Zitadel ourselves, or do we need help?
Either is workable, and the answer depends on the platform skills you already have. Keycloak needs a production relational database, supports the Operator on Kubernetes and documents high availability designs that rely on a synchronously replicated database. Zitadel supports PostgreSQL 14 to 18 and recommends Kubernetes with the official Helm chart for high availability. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps evaluate and implement tenant identity
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so tenant identity runs where your customer data already lives. We start from a written scope that compares Keycloak realms and Organizations against Zitadel instances and organizations for your specific product model.
How we scope
- Map each tenant type your product needs, including customer admins, end users and internal support staff
- Record which per-customer identity providers must be brokered and which protocols each one uses
- Agree in writing whether tenants need separate databases, shared realms or one instance with isolated organizations
- Confirm license obligations for your deployment model before any build work starts
How we build
- Configure a Keycloak realm or Zitadel instance and organization model that matches the agreed tenancy design
- Set up per-customer identity provider brokering and test login flows for each tenant type
- Delegate tenant administration to customer admins with role scopes limited to their own organization
- Run a PostgreSQL or other supported database setup and document the backup and upgrade path for the chosen platform
How we hand over
- Deliver architecture notes, tenant onboarding runbooks and admin delegation guides in writing
- Document realm or organization configuration as code so changes can be reviewed and reproduced
- Provide test evidence for tenant isolation, brokering and role boundaries before handover
- Walk your platform and security teams through the operating model and the open items they must confirm
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan upgrades against each platform's release cadence and document any breaking changes that affect tenants
- Repeat tenant isolation tests after each upgrade or new identity provider is added
- Confirm retainer scope, response expectations and quoted effort with your team in writing
