LiveKit

Last reviewed Aug 26, 2026 · 835 words

Host LiveKit when you are building something; host Jitsi when you want to have a meeting. LiveKit is an SFU plus SDKs, not a product with a join page, and its 20,500 stars come from developers putting it under their own apps, from Element Call, and from voice-AI agents that need sub-second audio. If what you want is a video call for the family, Jitsi Meet is the answer and this guide has just saved you a weekend. If you need real-time audio, video or data inside software you control, LiveKit is the best open-source stack for it, and the rules for running it are short.

One binary, one YAML file, and it works on a LAN in 5 minutes

livekit-server --dev starts a server with the key pair devkey / secret, and lk token create --api-key devkey --api-secret secret --join --room test --identity alice gives you a token to paste into any of the example apps. That is the whole development loop. The real config is not much longer:

port: 7880
rtc:
  tcp_port: 7881
  port_range_start: 50000
  port_range_end: 60000
  use_external_ip: true
keys:
  APIfz9kd3: a-long-random-secret
turn:
  enabled: true
  domain: turn.example.com
  tls_port: 5349
  udp_port: 3478

Run it as docker run --network host -v $PWD/livekit.yaml:/etc/livekit.yaml livekit/livekit-server --config /etc/livekit.yaml. Host networking is deliberate: publishing 10,000 UDP ports through Docker's NAT is slow and flaky, and the docs recommend host mode for exactly that reason. Put Caddy in front of 7880 for the WebSocket signalling over TLS, and clients connect to wss://livekit.example.com.

UDP first, TCP second, TURN last, and the order decides quality

Media wants UDP: open 50000 to 60000 inbound on the firewall and set use_external_ip so the server advertises its public address. When a client's network blocks that range (hotels, some offices), LiveKit falls back to TCP on 7881, which works with more jitter. When even that is blocked, the built-in TURN server relays over TLS on 5349, which looks like HTTPS to a firewall and nearly always gets through. Enable all three from day one; the calls that "sometimes have no video for one person" are almost always a missing fallback. A separate coturn is unnecessary because the TURN server is built in, but it does need a real certificate for turn.example.com.

Bandwidth is the limit before CPU. An SFU forwards each publisher's stream to every subscriber, so a 6-person call at 720p costs the server roughly 5 outbound streams per participant, around 30 to 40 Mbps total. Simulcast, on by default in the SDKs, lets the server send smaller layers to constrained clients, which is why a 10-person LiveKit call survives on a 100 Mbps uplink where a naive implementation would not.

Multi-node needs Redis, and most self-hosters should stop at one node

A single server handles hundreds of concurrent participants on a 4-core VM with 512 MB to 1 GB of RAM, which covers every homelab and most small products. Beyond that you add a redis: block to the config and run several servers behind one DNS name; Redis coordinates which node owns which room and routes participants. That is also the point where "complex to operate at scale" becomes true: region-aware routing, node draining for upgrades and observability become your job, and the company's hosted cloud is the honest comparison.

Egress and Ingress are separate services with separate costs

Recording a room to MP4, streaming it out over RTMP or HLS, or compositing a layout is done by Egress, a separate service that renders with headless Chrome and needs 2 or more dedicated cores per concurrent recording. Ingress does the reverse, bringing RTMP or WHIP streams into a room. Both are optional, both need Redis even on a single node, and both are why the catalogue's 512 MB is a floor for the core server only. Budget separately if recording is a requirement.

Where you will most likely meet it: Element Call

The largest self-hosted deployment pattern is Matrix: a Synapse homeserver, Element Call as the calling UI, and LiveKit as the media backend under it. If that is your goal, follow Element's MatrixRTC documentation for the JWT service that bridges Matrix auth to LiveKit tokens; the LiveKit half is exactly the single-node config above.

What I'd do

One LiveKit server in host networking mode on a VM with a public IP, UDP 50000 to 60000 and TCP 7881 open, built-in TURN on 5349 with a real certificate, Caddy for signalling, keys generated with lk rather than typed. Redis only if you add Egress or a second node. If at any point you notice you are writing a join page and a lobby, reconsider Jitsi; if you are writing an app, you are in the right place.