LiveKit Cloud → Self-Hosted

Self-hosting buys control of the SIP path, the relay path and the version of every component, plus the ability to fix a media-layer problem instead of filing a ticket about it. What it costs is everything the managed platform was quietly doing on your behalf, paid in operational work that stays invisible until the day it is not. I scope that trade honestly rather than assuming it favors moving.

Locked-down corporate, hotel and hospital networks allow outbound 443 and little else, which breaks the signalling websocket and the TURN relay at the same time. A layer-7 reverse proxy only solves the first, because TURN over TLS is not HTTP and cannot be proxied at layer 7. The build I run terminates both on a single 443 listener by reading the SNI out of the TLS ClientHello and routing the raw connection by hostname.

SIP trunks and dispatch rules do not live on the media server, they live in Redis, and a stock Redis container ships with no persistence configured. Recreating it empties the store, provisioning hands back brand-new trunk identifiers, and every id cached in your own database of record is stale until something tries to use one. That is a production failure I have already been on the wrong end of, and the migration accounts for it.

Where media actually flows is decided by ICE rather than by the architecture diagram: when a client network blocks outbound UDP, the only workable path is a relay candidate through TURN, and a relay that is not reachable on a permitted port presents as a media fault rather than a network one. Co-locating the media server, SIP, Redis and TLS termination on one host also means nothing bounds any one of them without explicit resource limits. Both are configured during the migration rather than discovered in production.

Region topology is a requirement that shapes the target architecture rather than a setting to switch on. It changes where media terminates, which carrier interconnects make sense, and what the TLS and DNS edge has to look like. Deployments spanning several regions push the work into a larger or phased engagement, and I scope it that way rather than folding it into one cutover.

An agent worker is a long-lived process holding live sessions, so restarting it in place is not a deploy, it is a mass disconnect, and a dropped call cannot be retried by the client the way an HTTP request can. What is running is also more than the code: an image tag, a runtime environment and a unit file on a host. Handover covers deploying against that reality, with a snapshot taken before each change so a rollback restores all of it.