Eh bien, bien que je ne sois pas un expert, j’ai l’intention de partager mes dernières découvertes sur Discourse. Principalement issues de l’expérience et de l’erreur 
Je partagerai volontiers ces informations une fois que j’aurai terminé et que j’aurai le temps de le faire. Le point clé de l’auto-hébergement est que chaque serveur est géré personnellement, de sorte que les configurations de sécurité varient d’un serveur à l’autre.
Dans mon cas, j’utilise Nginx comme proxy inverse ; d’autres utilisent Nginx Proxy, Caddy, Traefik, et ainsi de suite. De plus, certains d’entre nous préfèrent utiliser un réseau partagé de Docker, tandis que d’autres utilisent leur pont natif (afin que toutes les applications puissent se « voir »).
La chose la plus importante lors de l’hébergement de Livekit est de définir les secrets, de configurer les bonnes permissions et de durcir le modèle que Docker utilise, afin de limiter autant que possible. Étant donné qu’il s’agit d’un réseau public et que le projet lui-même est aux premiers stades de développement, il vaut mieux prévenir que guérir.
Je pense qu’ils offrent un service Cloud, mais l’auto-hébergement est bien plus qu’un site web (!)
LiveKit est composé de plusieurs couches : des services API, du routage pour la découverte des nœuds, un RTC central qui gère les salles et les participants, le traitement multimédia (SFU) qui gère la transmission RTP et le streaming adaptatif, le stockage pour la mise en cache (tel que Redis), et une couche d’infrastructure qui comprend la télémétrie et la configuration.
Peut-être que quelqu’un de l’équipe Discourse ou un utilisateur plus expérimenté peut me corriger si je me trompe, mais je comprends que dans ce cas, il serait nécessaire (ou un outil similaire) d’avoir les sous-domaines requis pour se connecter.
De toute façon, vous pourriez aussi le faire en interne, mais pour certaines actions, des certificats sont nécessaires et ceux générés localement ne fonctionnent pas toujours.