Multitenant deployment of Jitsi

@Aaron_K_van_Meerten what is the recommended approach for multi tenant deployment of Jitsi? E.g. we are going to share one Jitsi instance for multiple tenants, and also we would like to restrict users from tenantA to join meetings of tenantB.

Just to follow up on this topic from the Jitsi Call today — it would be really helpful to have more clarity on the multi-tenancy strategy that is currently being used by Jitsi in Production. More specifically, understanding the specifics on additional prosody modules or logic, as well as nginx config and config.js details to support separation between tenants, supporting a /tenant/meetingId URL structure, tenant/subdomain sequestering in JWT tokens/claims, and whatever “dynamic tenant MUC” setup that was mentioned on the call today.

Thanks a lot for all your help with this!


@Aaron_K_van_Meerten could you please take a look?

Hi, I’ll be working on this over the next week or so. The process will be to move the prosody modules into the open source, and develop documentation around this setup. This isn’t my main work priority this week so I may not have anything to show until probably late next week. If you haven’t heard anything by the next community call feel free to ask about it again and we’ll have an update.



@Aaron_K_van_Meerten here is what I have found related to multi tenancy.

  1. Official Jitsi Meet page generates muc hostname based on url.
    E.g. if you visit URL, then config.hosts.muc will be set to Subdomain here is orange. So, is it correct, that putting subdomain names to muc we can achieve multi tenant setup? What else config should be set for Prosody?
  2. Now I am aware about only two config options:
    enable_domain_verifiation should be set to true
    muc_mapper_domain_base should be set to

The question is: is it enough or something else should be done?

Thanks a lot for all your help with this!!!

@Aaron_K_van_Meerten I’m curious about the multi-tenancy approach. Is this understanding correct?

Jitsi-Meet (JS) would use
A prosody plugin similar to mod_filter_iq_rayo rewrites that jid to
and “” is configured in the prosody cfg as a muc.

Is that correct?
Is just that prosody plugin missing from jitsi-meet/tree/master/resources/prosody-plugins ?


That’s basically correct. We call the


syntax the “internal” representation as this module rewrites all IQs which reference this value in incoming and outgoing hooks. This way the client only has to know about the “external” representation below, and we don’t have to pre-provision tenants in the prosody configuration

However certain pieces such as prosody modules end up parsing the internal representation as well.

@ivanr you are correct. The final step would be to enable the mod_muc_domain_mapper module which we haven’t yet release but I hope to get time for mid-next week.

@Aaron_K_van_Meerten good news, thanks a lot!