Implement multi-site (multi-tenant) feature

[nicksrandall]

I'm looking for a multi-site feature much like Wordpress and can see that it is on the long-term road map for strapi. I'd like to help get this feature implemented and am looking for some direction from the core maintainers before I begin.

Has anybody spent the time to consider how this might be accomplished?

For those who are unfamiliar with "multisite" (perhaps a better name would be multi-tenant), I will give a brief explanation. As a user, I'd like to manage multiple clients (front-ends) with one backend installation (sever). The multisite backend will provide a way to manage users as well as give specific users access to specific sites. I would also be able to create and manage sites, each one configured with a specific url namespace.

For example, Lets say I had two clients; one for my blog and another for my online store. Each site would maintain it's own api which would be prefixed with a configurable value. So, for example, I could access my posts at "site.com/blog/posts" and could access my products at "site.com/store/products". Likewise, I could access the admin for my blog at "site.com/blog/admin" and the admin for my store at "site.com/store/admin". For all intensive purposes, these two sites are completely isolated except for that fact that they run on the same server, the same database, and the same core libraries.

[Aurelsicoko]

As you said, it's on the long-term roadmap for Strapi. Currently, I don't think the project is mature and stable enough to handle this use case. So many things are still in work in progress, the plugin implementation isn't finished yet and we're still in alpha.

However, I would love to know how you would like to implement this feature. We could anticipate some things and make it easier to develop in the future 👍

[Mr-Black-Dahlia]

@nicksrandall @Aurelsicoko What is the idea for this? Core functionality or seperated into a plugin? To add I would prefer subdomains with an option to attach a TLD. I am creating an app where my customer will need their own separated by a subdomain. (business1.site.com, business2.site.com)

[Aurelsicoko]

@indiecore-fm For now, it should be a core functionality, but we're working on the plugin architecture and I still don't know if a feature like this could be handled by a plugin. It would make more sense to use a plugin for this but it will impact so many things...

Also, should we generate two projects (one for each subdomain) without the administration and another one with the administration only? With configurations, we could connect them together to the same administration.

Or, we should update the architecture of a current project and split into multiple apps. The plugin will load the files by itself and mount them into the main app.

- /admin
- /apps
  - /one
    - /api
    - /config
    - /plugins
    - package.json
  - /two
    - /api
    - /config
    - /plugins
    - package.json

There are different approaches to the multisite feature, I don't have enough background to know what's the best way to do it... If you have any thoughts or ideas to share, I would like to hear about them :)

[Mr-Black-Dahlia]

@Aurelsicoko I agree that it should be core functionality with the option to turn it on or off for certain use cases.

I have scoured the web and noticed there are a lot of different ways to truly implement a multi-site solution. I'm going to give my personal view on how it should implemented. I also personally recommend instead of limiting Strapi to a one use case, we allow two different types.

Type 1:

The way you shown above would be a great way to allow a company to easily make multiple client backends. It looks like it is handled by the same admin panel and has it's own custom api for each "app". Then a super admin could log into each "sub app" and manage it. This case you could use one admin panel. Depending on the user role and who they are attached too, they would just see there info in the admin section.

Type 2:

You build your app just like normal and once the backend is finished, Strapi allows for the base app to be copied over in a blank state for a new tenant. This use case a user can build an app and then resell that app easily to multiple tenants. It would use the same codebase without needing to have an apps folder with multiple "sub apps" in there. So if I make a change to the base app, it reflects across all tenants. This would need an admin panel per subdomain. (or could be one master admin panel like you said before that superadmins could manage all tenants) and a frontend solution is coded for each tenant to mange their settings/content addition. In this use case I would allow the creation of a new tenant via API as well.

I would strongly suggest looking into both. I know a lot of people are looking for an easier way to do type 2.

[Aurelsicoko]

I've added a new card in our public roadmap on Product Board (see https://portal.productboard.com/strapi/c/36-multi-tenancy). Don't hesitate to give me insights and share your thoughts. I've referenced this issue in the card.

Since the needs have been discussed enough, I'm closing the issue.

[vinayagg]

Another way to do this is to create project / customer folders with base apps linking to common folders like this:

• /superAdminV2.0 (super admin access for all 2.0 apps)
• /superAdminV3.0 (super admin access for all 3.0 apps)
• /adminV2.0
• /adminV3.0
• /pluginsV2.0
• /pluginsV3.0
• /apps
  • /one
    • /admin (links to /adminV2.0, can be upgraded by linking to /adminV3.0)
    • /api
    • /config
    • /plugins (links to /pluginsV2.0, can be upgraded by linking to /pluginsV3.0)
    • /pluginsCustom (Customer / project specific plugins)
    • package.json

This kind of architecture would allow projects be upgraded that have not deviated from base code but also allow customers/projects to maintain their version if they had to customize something specific.

[Vadorequest]

We also need this feature, here are our current needs:

• Providing a backoffice to our customers, where each user can connect to its own tenant and access its tenant's data only.
• Theming capabilities of the backoffice, per tenant, would nice to have.
• Advanced permissions and roles for internal users, basically need to configure whom can view which tables, or has update/delete permissions on which tables.
• We need an API as well in order to fetch the data from our apps. (GraphQL)
• The backoffice needs to be flexible about UI components/views so that we can create our own workflows, views and components.
• We plan on building a common base for all, but having the capability to customize a the UI/workflow of a specific customer in a maintainable way would be awesome.

I believe those needs confirm more or less the above design.

[vinayagg]

Another requirement can be - groups or organizations
Data can be owned by organization (or group) rather than individual. Individuals join and leave companies, data stays with the company.

[goxiaoy]

This is a really good feature for someone who want to build a Saas platform based on Strapi, or even for Strapi team self (instead of Paas)

I have some experiences on Saas platform and multi-tenant, so here are some of my opinions

• Code base:

  • Every tenant should share the same code. This will apparantly reduce the code maintainance and make features availbale for every tenant once developed. Instead of code structure like /apps/one /apps/two, it's more reasonable to use the existing plugin like structure /apps/module1 /apps/module2, and by adding a permission module like existing user-permission plugin, you can control which tenant can use module1 or module2 or both, we can called tenant-feature. And even you can add a role like feature may called tenant-edition to provide editions like enterprise team . If your tenant wants the source code of modules he want, it's better to create a separate repository or branch

  • Customization like themes. This should be available for tenant self. By using module like tenant-setting, tenant could update theme settings easily.

  • Host admin and tenant admin. Host admin should have some module like tenant-management to manage tenant. Host admin can have feature like impersonator to login in as tenant admin to see information in tenant for customer debugging.

• Data Access

  • Strapi provides powerful contentType builder to quickly deliver business models, so if you want to open this feature to your tenant, the best tenancy model is database-per-tenant. You have a host side database to store models like tenant,tenant-feature,tenant-edition
    , and for every tenant , he owns his own database so that he can fully use the power of contentType builder. As for the deployment, you can share the same db instace like Amazon RDS but different database. Or even you want to provide SLA for important tenant which may have a large mount of read-write, you can use infrastructure as code to create db instances for this tenant! If you want to deliver the same schema for every tenant, you can totally use single-tenant app with single-tenant database

• How to:

  • create global object tenant like User object in Strapi context
  • use middleware to resolve tenant object. For example like business1.site.com, business2.site.com you can create a UrlTenantResolver to resolve tenant object
  • data access. Resolve database config by tenant. determine use host db or tenant db. If you want to use single-tenant app with single-tenant database, you should really be care of the data isolation. Some feature like GlobalDataFilter should by applied to the whole data access layer to prevent one tenant from seeing data not belongs to this tenant

• Conclusion：

  • plugins to development: tenant-management, you may also want tenant-setting tenant-feature tenant-edition,or tenant-seeder to initial database for database-per-tenant or create some initial data
  • core code change: data access layer should have some feature like GlobalDataFilter to isolate data. TenantDatabaseConfigResolver to resolve tenant db info.
  • development change: use infrastructure as code to create db instances if needed

[goxiaoy]

Another requirement can be - groups or organizations
Data can be owned by organization (or group) rather than individual. Individuals join and leave companies, data stays with the company.

organizations can be built top on tenant with tree structure

[abdullahe]

Is this feature implemented?