Request for Multi-Tenancy Support in Rocket.Chat for Enhanced Scalability

[andreiZi]

Is your feature request related to a problem? Please describe.

Currently, to run multiple instances of Rocket.Chat, we need to deploy multiple separate installations. This increases infrastructure and management overhead and doesn't provide a seamless experience for administrators and users who need to manage and use multiple chats.

Describe the solution you'd like

We propose multi-tenancy support in Rocket.Chat, allowing multiple isolated chat instances on a single Rocket.Chat server. This would mean that different groups or organizations could share a single Rocket.Chat installation while maintaining their own separate users, channels, messages, and settings. It's a feature that could be toggled on/off by server admins based on the needs of their installation.

Describe alternatives you've considered

One alternative to this approach is to continue with the current setup, running multiple separate installations of Rocket.Chat for each group or organization. This, however, doesn't scale well and involves increased overhead in terms of maintenance and resource usage.

Another alternative could be to use teams or channels to simulate separate instances within one Rocket.Chat installation, but this doesn't provide the same level of isolation and can lead to confusion and potential data leaks between teams.

Additional context

Multi-tenancy is a common feature in many similar software solutions and can significantly enhance the flexibility and scalability of Rocket.Chat, particularly for service providers who need to provide chat services to multiple different groups or organizations. This feature would place Rocket.Chat in a more competitive position in relation to other enterprise-level chat software.

[hallo43]

Using Rocket.Chat for multi-tenant setups does not necessarily require modifying the Rocket.Chat core. Instead, we can handle this at the Proxy level.

If a single Rocket.Chat core is shared among multiple tenants, it will become slow, and tenants will affect each other. For example, if Company A has 500 users, it could slow down Rocket.Chat, negatively impacting other companies with only 50 users.

I believe it would be better to use a separate Rocket.Chat core for each tenant and forward requests to the correct Rocket.Chat instance based on the tenant's URL.

For example:

• tenantA.rocket.chat will forward requests to http://tenantA:3000
• tenantB.rocket.chat will forward requests to http://tenantB:3000

To implement this, you can add each tenant’s URL to the Origin header. Then, at the Proxy (NGINX), extract the tenant code based on the Origin and forward the request accordingly.