Multi domains without communication possible between them?


Is it possible to have only one installation for multiples guest without any communication between them ?

for example room room on will be different than room on ?

Best regards

This sounds like two separate deployments.

The multidomain we support is: and and these are two different rooms.

okay so how could I achieve that without multiple deployments ?
For now I have a 404 when I trying to acces to

I thought to use domaines for secure domain, in this case how could I do with authentification ?

as example:
username: tenant1 -> can only create room in*
username: tenant2 -> can only create room in*

Or better, directly restrict creation of room like

username: tenant1 -> can only create room
username: tenant2 -> can only create room and

Best regards

Are you using the latest unstable packages, as it comes pre-configure with multidomain support? If you are using stable you need to configure your deployment based on this example

Thanks I’ll check that

Do you have any idea about how I could solve my auth requirements ?

We do not have such a feature. We use multitenant deployments with jwt, and in jwt you can have such restrictions.

Okay thanks,

we have multiples clients and we would attribute to a client fixed rooms (example client1 can only create rooms client1_room1 and client1_room2)
only authenticated people can “create” room, anonymous can only join (that’s why secure domain look interresting)

I suppose it’s possible to mix jtw and secure domain config ?

My first question was a little “XY” so should I start a new thread ? (the idea of multidomain was a temporary workaround)


After a quick look jtw look like exactly what I need,
I have some question about jwt, should I start a new thread or continue here is fine ?

Best regard

Here is fine.

If I understood correctly token will not change anything in the moderation system ? (First join is the moderator of the room) In this case I also need to use something like this ?

the enableUserRolesBasedOnToken property in /etc/hitsi/meet/<FQDN>-config.js is only in the case I want guests without token right ? what about enableFeaturesBasedOnToken ?

This is something we implemented, but never used and is to allow different features based on the list of allowed features coming from the token.

This you will want to enable if you want to allow stuff like recording, kicking, muting to be available only to participants joining with a token.