Self-Hosting Architecture and Decision Framework

Running LiveKit on your own infrastructure gives you total control over data, latency, and cost at scale. It also means you own every operational concern: upgrades, security patches, monitoring, scaling, and disaster recovery. This chapter maps out the architecture you will build across this course and helps you decide whether self-hosting is the right call for your project.

What you'll learn

• A decision framework for choosing between LiveKit Cloud and self-hosting
• The full architecture of a self-hosted deployment: SFU, signaling, TURN, Redis, agent workers
• Network topology: ports, protocols, and NAT traversal
• Hardware requirements and sizing for target concurrent sessions

When to self-host vs LiveKit Cloud

LiveKit Cloud is the fastest path to production. It handles scaling, monitoring, upgrades, and global distribution. For most teams, it is the right starting point. But specific scenarios make self-hosting not just preferred but required.

Data sovereignty. Regulated industries -- healthcare, finance, government -- often mandate that media streams never leave specific geographic boundaries or networks. Self-hosting lets you run LiveKit inside your own VPC, on-premises data center, or air-gapped network.

Latency control. When your users are concentrated in a region without a LiveKit Cloud point of presence, self-hosting in a nearby data center shaves critical milliseconds off the media path.

Cost at scale. At very high volumes -- thousands of concurrent rooms -- dedicated infrastructure economics can become favorable. This crossover point is higher than most teams expect.

Custom configuration. Self-hosting gives you access to every configuration knob: codec settings, TURN behavior, port ranges, Redis topology, and resource limits.

Architecture overview

A production self-hosted LiveKit deployment consists of six components working together. Every component after the first is optional for development, but all are required for production.

Network topology

LiveKit uses three distinct port ranges, each with different networking requirements.

The livekit-server config.yaml structure

Every LiveKit server reads a single YAML configuration file. Here is the structure with all key sections annotated.

# HTTP API and WebSocket signaling port
port: 7880

# WebRTC media configuration
rtc:
port_range_start: 50000
port_range_end: 60000
tcp_port: 7881
use_external_ip: true          # Discover public IP for ICE candidates

# Redis for multi-node coordination
redis:
address: redis:6379
# password: your-redis-password
# use_tls: true
# db: 0

# API key/secret pairs (multiple supported for rotation)
keys:
your-api-key: your-api-secret

# Built-in TURN server
turn:
enabled: true
domain: turn.example.com
tls_port: 5349
# udp_port: 3478

# Logging
logging:
level: info                     # debug, info, warn, error
json: true                      # Structured JSON logs for production

# Resource limits
limit:
num_tracks: 0                   # 0 = unlimited
bytes_per_sec: 0                # 0 = unlimited

Hardware requirements and sizing

Requirements vary significantly based on expected load. LiveKit is CPU-bound for packet forwarding -- CPU is almost always the bottleneck before memory or network.

Single-node development or testing:

• 2 CPU cores, 4 GB RAM
• 100 Mbps network
• Any modern Linux distribution (Ubuntu 22.04+ recommended)
• Docker or direct binary installation

Production (per LiveKit server node):

• 4-8 CPU cores, 8-16 GB RAM
• 1 Gbps network (dedicated, not shared)
• Low-latency storage for logs
• Linux with kernel 5.4+ for optimal UDP performance

Agent worker nodes (if running AI agents):

• CPU-only agents: 2-4 cores, 4-8 GB RAM per worker
• GPU agents (STT/TTS): 1 GPU (T4 or better), 4 cores, 16 GB RAM
• Scale agent replicas independently from LiveKit server nodes

# Quick check: verify your server meets minimum requirements
echo "CPU cores: $(nproc)"
echo "RAM: $(free -h | awk '/^Mem:/ {print $2}')"
echo "Kernel: $(uname -r)"
echo "Docker: $(docker --version 2>/dev/null || echo 'not installed')"

# Check that required ports are not already in use
ss -tulnp | grep -E ':(7880|7881|3478|5349) '

Capacity estimates (4-core, 8 GB node):

What you learned

• Self-hosting is justified by data sovereignty, latency requirements, cost at scale, or configuration needs -- not by default
• A production deployment includes LiveKit Server, Redis, TURN, a reverse proxy, agent workers, and monitoring
• Signaling (WebSocket/HTTPS) and media (UDP) follow different network paths with different requirements
• The config.yaml controls ports, Redis, keys, TURN, logging, and resource limits
• Hardware sizing is CPU-bound; measure your actual workload before planning capacity

Next up

In the next chapter, you will deploy LiveKit on Kubernetes using Helm charts, configure Redis for multi-node coordination, and set up TURN for NAT traversal.