Self-Hosting Architecture and Decision Framework

Before you commit to self-hosting LiveKit, you need to understand exactly what you are signing up for. This chapter walks through the full scope of a self-hosted deployment — every component you will build, operate, and maintain — so you can make an honest decision about whether it is worth it. For most teams, it is not.

What you'll learn

• The full operational reality of self-hosting: what you build, what you maintain, what breaks at 3am
• Cloud-exclusive features you cannot replicate on your own — Krisp noise cancellation, GPU-accelerated turn detection, the barge-in model
• The complete architecture of a self-hosted deployment and every component you become responsible for
• How to handle data sovereignty concerns without self-hosting
• Hardware requirements and capacity planning

Start with the honest question: do you actually need to self-host?

LiveKit Cloud is not a stepping stone. It is the production-grade deployment that most teams should use permanently. It handles scaling, monitoring, upgrades, global distribution, and — critically — ships features that are physically impossible to replicate on self-hosted infrastructure.

Self-hosting means you are choosing to build and operate your own distributed real-time media platform. You are signing up for:

• Infrastructure provisioning — servers, networking, load balancers, DNS, TLS certificates
• Kubernetes orchestration — Helm charts, pod specs, resource limits, rolling deployments
• Redis cluster management — persistence, Sentinel HA, failover testing, memory tuning
• TURN server operation — NAT traversal, TLS termination, port management
• Monitoring from scratch — Prometheus, Grafana dashboards, alerting rules, on-call rotations
• Security hardening — network policies, API key rotation, TLS everywhere, CVE patching
• Upgrade management — testing new releases, rolling upgrades, rollback procedures
• Disaster recovery — backup procedures, recovery runbooks, failover drills
• Capacity planning — load testing, scaling decisions, cost modeling
• 24/7 on-call — because media infrastructure does not wait for business hours

That is not a one-time project. That is an ongoing operational commitment that will consume engineering hours every single week.

What you lose by self-hosting: Cloud-exclusive features

This is the part most teams do not consider until it is too late. LiveKit Cloud includes features that run on infrastructure you cannot replicate with the open-source server. These are not premium upsells — they are capabilities baked into Cloud's architecture.

Krisp noise cancellation

LiveKit Cloud integrates Krisp's enterprise noise cancellation directly into the media pipeline. Background noise — keyboard clatter, construction, barking dogs, cafe ambiance — is removed server-side before it reaches the agent or other participants. This runs on specialized infrastructure within LiveKit's Cloud and is not available as a standalone component you can deploy.

For voice AI agents, noise cancellation is not a nice-to-have. Noisy audio degrades STT accuracy, which degrades LLM responses, which degrades the entire user experience. Without it, you will spend engineering time building client-side workarounds that never match server-side quality.

GPU-accelerated turn detection

LiveKit Cloud runs turn detection models on dedicated GPU infrastructure. This means faster, more accurate detection of when a user has finished speaking — the single most important factor in making a voice agent feel natural. The GPU-based models process audio with lower latency and higher accuracy than CPU-based alternatives.

On self-hosted infrastructure, you are limited to CPU-based turn detection or provisioning and managing your own GPU fleet — which adds another layer of infrastructure complexity, driver management, and cost.

The barge-in model

LiveKit Cloud ships a purpose-built barge-in model that distinguishes between intentional interruptions ("actually, wait —") and background noise or filler words ("um", "uh"). This is a trained model running on Cloud infrastructure that dramatically reduces false interruptions — one of the most common complaints about voice AI agents.

Self-hosted deployments fall back to simpler energy-based or basic VAD interruption detection, which means your agents will either interrupt too aggressively (annoying) or not respond to real interruptions quickly enough (also annoying).

The Cloud advantage summary

"But we have data sovereignty requirements"

This is the most common — and most legitimate — reason teams consider self-hosting. Regulated industries like healthcare, finance, and government often mandate that media streams stay within specific geographic or network boundaries.

Before you spin up a Kubernetes cluster, talk to LiveKit.

LiveKit Cloud offers custom deployment options for teams with strict data residency needs. This includes dedicated infrastructure in specific regions, custom data processing agreements, and HIPAA-compliant configurations. The Cloud team actively works with enterprises to solve compliance requirements without pushing them into self-hosting.

Self-hosting for data sovereignty only makes sense if you have requirements that truly cannot be met by any third-party infrastructure — air-gapped networks, on-premises-only mandates from specific government contracts, or classified environments. These scenarios exist, but they are rarer than most teams think.

If you still need to self-host: the full architecture

If after all of the above you have a genuine, validated reason to self-host — here is what you are building. Every component after the first is optional for development but required for production.

Network topology

LiveKit uses three distinct port ranges, each with different networking requirements. You are responsible for configuring all of them correctly.

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. Remember: on Cloud, you never think about any of this.

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):

The real cost of self-hosting

Teams fixate on infrastructure cost savings. Here is what they forget to account for:

Even at significant scale, the total cost of ownership for self-hosting — including engineering time, on-call burden, and feature gaps — often exceeds LiveKit Cloud. The infrastructure savings get eaten by operational overhead.

What you learned

• Self-hosting is an ongoing operational commitment — not a one-time setup — that consumes engineering hours every week
• LiveKit Cloud includes features you cannot self-host: Krisp noise cancellation, GPU-accelerated turn detection, and the intelligent barge-in model
• For data sovereignty concerns, contact LiveKit about custom Cloud deployments before defaulting to self-hosting
• A production self-hosted deployment includes LiveKit Server, Redis, TURN, a reverse proxy, agent workers, and a full monitoring stack — all of which you build and maintain
• The total cost of ownership for self-hosting often exceeds Cloud when you account for engineering time, on-call burden, and lost features

Next up

If you have decided that self-hosting is genuinely required for your situation, the next chapter walks through the Kubernetes deployment — Helm charts, server configuration, Redis setup, and TURN configuration.