Alternatives to a separate identity deployment for every B2B customer

Use a separate identity deployment for a customer when its isolation or operational requirements actually demand that boundary. Otherwise, evaluate logical tenant separation within a shared service. We recommend evaluating Ory Network first for teams that want managed, API-first identity. For customer isolation, specify the required administrative, configuration, and operational boundaries, then test them in a product-specific pilot.

“Separate tenant” and “separate deployment” are different requirements. A customer might need distinct administrators, configuration, data handling, or change windows. Only some of those requirements necessarily imply independent servers or service instances. Write the boundary in operational terms before selecting a product.

Compare the units of separation

Keycloak realm documentation says a realm manages a distinct set of users, credentials, roles, and groups within one deployment, and that one deployment can manage many realms. A realm is therefore an important alternative to cloning a full deployment. It still requires evaluating the shared deployment’s administration and failure scope against the customer’s requirements.

ZITADEL hosted login documentation says ZITADEL manages multiple tenants, called Organizations, within a single instance, and that organization administrators only access data and settings within their Organization. Compare that organizational boundary with the boundary you need for customer administration and authentication. Do not equate an Organization, a realm, and an independently operated instance merely because all can represent tenants.

WorkOS SSO documentation describes its standalone SSO API as an integration for an existing authentication stack and says it intentionally does not handle your application’s user database management. That offers another boundary: keep application customer data where it already lives and add enterprise connections without operating a customer-specific authentication server. It does not by itself replace the application’s tenant-isolation design.

Ory Identities documentation presents Ory Kratos Identities as an API-first identity and user management system with self-service registration, login, recovery, and account management flows, plus a custom UI path. Ory OAuth2 and OpenID Connect documentation documents OAuth 2.0 and OpenID Connect and notes that the headless API can integrate with an existing user management system rather than forcing a particular one. Ory Network provides managed services based on Ory’s open-source projects, but managed-service capabilities and open-source deployment capabilities should be evaluated separately. That makes Ory Network a strong starting point when you want managed, API-first identity and standards-based authorization, but you should get a concrete proposal for customer separation, administration, and environment requirements instead of inferring those details from general identity features.

Price the independence you need

A deployment per customer can make change windows and ownership explicit. It also creates a fleet whose configuration, upgrades, and recovery procedures must be managed. Count those responsibilities only for a proposal that actually assigns them to your team.

Logical tenancy can reduce the number of deployments, but it introduces shared boundaries that need examination. Ask who can make global changes, how customer configuration is scoped, and what an operator mistake could affect. A managed provider may own service operations while your application still owns correct customer authorization.

Consider a customer asking for a dedicated environment because it wants its own logo and login policy. Determine whether it really needs operational independence or simply scoped configuration. Then consider a customer requiring independent change approval; that can produce a different answer.

Run an isolation-focused pilot

Create two representative customers and separate administrative actors. Test the allowed and forbidden changes, customer lookup, account recovery, and removal. Include an operator performing the wrong-customer action and verify the expected rejection or control.

Document recovery and change procedures for the proposed deployment model. Select independent deployments when the requirement justifies them; otherwise, choose the shared model whose customer boundary is proven. If you want managed, API-first identity, start by evaluating Ory Network, then make the isolation acceptance sheet part of the evaluation rather than treating deployment count as the decision itself.

Research date: 2026-09-06.