The recommended approach is one Strapi deployment per site.

Single / Multi-Site and Channel Strapi: Simplistic Use-case

Overview

The recommended approach is one Strapi deployment per site. In this setup, a single deployment (one codebase and one database) powers one website. Your frontend pulls content from Strapi over the REST or GraphQL API.

Because content is delivered over an API, the same deployment can also serve more than one consumer, such as a website and a native app. In the diagram, Strapi deployment A sends content to Site A, App A, and Site B. This pattern is not multi-tenant. All consumers share one database, and there is no built-in way to silo content by site. As you add more consumers, the risk of cross-site data exposure increases, especially when sites differ in content or governance requirements.

How it works

1. Set up Strapi deployment A as the shared backend

2. Connect your consumers

   • Link Site A, App A, and Site B (or other frontends) to deployment A over the REST or GraphQL API

3. Deliver content from deployment A via API requests

When to choose this pattern

• A small number of closely related properties that can safely share content types and data, without major differences in content type structure

• Teams prepared to enforce isolation at the application and API layers

  • Admin RBAC Conditionals

  • Route Policies and/or Middlewares

Multi-project: Enterprise use case

Overview

With Strapi, you can purchase a multi-project setup. In this approach, a single codebase powers multiple Strapi deployments, and each deployment keeps its data in a separate database. This is ideal when several deployments share the same structure but require different content. It avoids code duplication and reduces the risk of cross-site data exposure.

This represents multi-tenancy in a truer sense, where data isolation is important or required.

How it works

1. Establish Codebase A as the shared application

2. Create additional Strapi deployments, one per site

3. Configure each deployment to use Codebase A with its own database and environment variables

4. Expose a unique API for each project

Example

A restaurant group plans to launch new sites for each restaurant. While the sites share the same information architecture and components, the menus and other specifics vary by location. They use Codebase A for all projects, with a separate Strapi deployment and database per restaurant to keep content siloed. Each deployment is independent and connects to its own database, allowing configuration, permissions, and workflows to vary by site. This setup reuses one codebase for efficient updates while preserving data isolation across sites.

When to choose this pattern

Note: This multi-project setup is available for an additional fee on top of the initial license. To learn more, please contact the sales team.

• Many similar sites or apps that align on the same data model and content types

• A clear need to isolate data and access per property while keeping engineering overhead predictable