# Multi-tenant architecture Who you sell to decides whether your app needs to be multi-tenant and how to model that in Clerk. Most apps fit one of three models: - [B2C](#b2c-business-to-consumer): You sell to individuals. Each person has one account, and you usually don't need Organizations. - [B2B](#b2b-business-to-business): You sell to businesses. Each person has one account and can belong to several Organizations. - [Platforms](#platforms): Your customers serve their own users. Use Organizations if those users can share accounts across customers, or a separate Clerk application for each customer if they can't. ## B2C: Business to consumer B2C companies focus on selling products or services directly to consumers. Examples include Netflix, Headspace, and Spotify. Clerk supports this model out of the box with little-to-no configuration. In a typical B2C app: - A user creates a single account with your service. - All users share one user pool. - Authentication connections enabled for the Clerk application instance are available to all users. - The application uses your company's branding, with no per-customer white-labeling. - The application is accessible under a single domain (for example: `example.com` or `app.example.com`). > Organizations are generally unnecessary in B2C apps because users typically sign up as individuals, rather than as part of a team, organization, or workspace. If the app adds shared resources, Organizations can represent those teams or workspaces. ## B2B: Business to business B2B companies sell to other businesses. Examples include GitHub, Vercel, Salesforce, Sentry, and Clerk. In multi-tenant B2B SaaS apps, Organizations (sometimes called teams or workspaces) manage users, memberships, and access to each customer's resources based on Roles. B2B SaaS applications with the following characteristics are well supported with Clerk: - A single application deployment that serves multiple business customers (multi-tenant) - A shared user pool in one Clerk application instance, where a user can sign in with one account and belong to multiple Organizations, with a different Role in each - Social connections enabled for the instance and Enterprise SSO connections linked to specific Organizations - Your own branding or elements of your customer's branding - A single domain for the application (for example, `app.example.com`) Some B2B apps also offer Personal Accounts outside their Organizations. For example, GitHub lets users create repositories under their personal account or an organization they belong to. Each Clerk application has separate [development and production instances](https://clerk.com/docs/guides/development/managing-environments.md), which don't share user accounts. Organizations within one instance share a user pool. If each customer needs an isolated pool or independent instance-level settings, use a separate Clerk application for each customer. The [Platforms model](#platforms) is one example. ## Platforms Platforms serve businesses that, in turn, serve their own users. Examples include e-commerce platforms like Shopify, e-learning platforms, and mortgage lending platforms. An e-learning platform, for example, might let universities create courses and enroll students. Each university has its own students, faculty, and administrators; a person using two universities may need an account in each. A platform customer may need: - Its own user pool, separate from other customers - A vanity domain such as `customer.example.com` or a custom domain such as `customer.com` - Its own branding, including authentication screens, SMS, and email templates - Its own authentication policies, enabled connections, and MFA requirements - Limits based on its subscription, such as the number of users it can invite to an Organization If customers can share a user pool and instance-level settings, an Organization can represent each customer. Organizations in the same Clerk application instance share a user pool, but can have customer-specific settings such as [Enterprise SSO connections](https://clerk.com/docs/guides/organizations/add-members/sso.md), available Roles through [Role Sets](https://clerk.com/docs/guides/organizations/control-access/role-sets.md), and [membership limits](https://clerk.com/docs/guides/organizations/configure.md#membership-limits). If customers need isolated user pools or independent instance-level settings, use separate Clerk applications. Organizations can still group users within each customer's application when those users need teams or workspaces. [Clerk for Platforms](https://clerk.com/platform) provides APIs to provision and configure applications for customers; see the [Platform API reference](https://clerk.com/docs/reference/platform-api) for current access requirements. ## Integrate Organizations with your application If you use Organizations, see how to [switch between them](https://clerk.com/docs/guides/organizations/create-and-manage.md#switch-between-organizations), [read the Active Organization](https://clerk.com/docs/reference/hooks/use-organization.md), and [check access](https://clerk.com/docs/guides/organizations/control-access/check-access.md). The [Organizations overview](https://clerk.com/docs/guides/organizations/overview.md#how-do-organizations-work) explains how these pieces fit together. --- ## Sitemap [Overview of all docs pages](https://clerk.com/docs/llms.txt)