Well, although I’m not an expert, I have pending to share my latest findings and discoveries in Discourse. Mainly from trial and error 
I will gladly share this information after finishing it and when I have time to do so. The point with self-hosting is that each server is managed personally, so security configurations vary from one server to another.
In my case, I use Nginx as a reverse proxy; others use Nginx Proxy, Caddy, Traefik, and so on. Additionally, some of us prefer to use a shared network from Docker, while others use their native bridge (so that all applications can see each other).
The most important thing when hosting Livekit is to set the secrets, set correct permissions, and harden the template that Docker uses, to limit everything as much as possible. Since it’s a public network and the project itself is in early stages of development, it’s better to be safe than sorry.
I think they offer a Cloud service, but self-hosting is more than a website (!)
LiveKit is composed of several layers: API services, routing for node discovery, a central RTC that manages rooms and participants, multimedia processing (SFU) that handles RTP forwarding and adaptive streaming, storage for caching (such as Redis), and an infrastructure layer that includes telemetry and configuration.
Maybe someone from the Discourse team or a more experienced user can correct me if I’m wrong, but I understand that in this case it would be necessary (or a similar tool) for you to have the required subdomains to connect.
Either way, you could also do it internally, but for certain actions, certificates are required and locally generated ones don’t always work.