Beh, anche se non sono un esperto, ho in sospeso la condivisione dei miei ultimi risultati e scoperte su Discourse. Principalmente basati su tentativi ed errori 
Condividerò volentieri queste informazioni dopo averle completate e quando avrò il tempo di farlo. Il punto del self-hosting è che ogni server viene gestito personalmente, quindi le configurazioni di sicurezza variano da un server all’altro.
Nel mio caso, uso Nginx come reverse proxy; altri usano Nginx Proxy, Caddy, Traefik, e così via. Inoltre, alcuni di noi preferiscono usare una rete condivisa da Docker, mentre altri usano il loro bridge nativo (in modo che tutte le applicazioni possano vedere le altre).
La cosa più importante quando si ospita Livekit è impostare i segreti, configurare i permessi corretti e rafforzare il template che Docker utilizza, per limitare tutto il più possibile. Dato che si tratta di una rete pubblica e il progetto stesso è nelle fasi iniziali di sviluppo, è meglio prevenire che curare.
Credo che offrano un servizio Cloud, ma il self-hosting è molto più di un semplice sito web (!)
LiveKit è composto da diversi livelli: servizi API, instradamento per la scoperta dei nodi, un RTC centrale che gestisce stanze e partecipanti, elaborazione multimediale (SFU) che gestisce l’inoltro RTP e lo streaming adattivo, archiviazione per la cache (come Redis) e un livello di infrastruttura che include telemetria e configurazione.
Forse qualcuno del team di Discourse o un utente più esperto può correggermi se sbaglio, ma capisco che in questo caso sarebbe necessario (o uno strumento simile) per avere i sottodomini richiesti per la connessione.
In ogni caso, potresti farlo anche internamente, ma per determinate azioni sono richiesti certificati e quelli generati localmente non funzionano sempre.