Introduction to Real-Time Interactive Streaming

In the modern digital landscape, the demand for real-time interactive video has skyrocketed. Traditional streaming protocols like HLS (HTTP Live Streaming) and DASH have served the industry well for one-way broadcasting, but they inherently introduce latencies ranging from 5 to 30 seconds. For use cases requiring true interactivity—such as live auctions, interactive gaming, virtual classrooms, and collaborative co-streaming—this delay breaks the user experience. To achieve sub-second latency, developers must look beyond traditional CDN architectures toward Selective Forwarding Units (SFUs) powered by WebRTC. Among the modern solutions available, LiveKit stands out as a highly scalable, developer-friendly open-source WebRTC stack.

Understanding LiveKit and the SFU Architecture

Before diving into the deployment process, it is essential to understand why LiveKit utilizing an SFU architecture is superior to older paradigms like MCU (Multipoint Control Unit) or simple Peer-to-Peer (P2P) networks.

Peer-to-Peer (P2P): In a P2P mesh network, every participant sends their media tracks directly to every other participant. While cost-effective, this approach fails exponentially as the participant count grows, since client upload bandwidth and CPU consumption scale at O(N^2).
Multipoint Control Unit (MCU): An MCU receives media streams from all publishers, decodes them, mixes them into a single composite stream, encodes it, and sends it to subscribers. While light on client resources, MCUs require massive server-side CPU infrastructure and introduce rendering delays due to transcoding.
Selective Forwarding Unit (SFU): An SFU acts as a smart media router. It receives incoming media streams from publishers and forwards them to subscribers without decoding or re-encoding the media packets. This keeps CPU utilization minimal, allows for dynamic bandwidth adaptation (Simulcast/SVC), and delivers latencies under 300 milliseconds.

LiveKit modernizes the SFU pattern by decoupling the media routing layer from application logic. Written in Go, it leverages HTTP/3 and WebRTC over UDP to ensure maximum throughput and resilience across varying network conditions.

Prerequisites and VPS Hardware Sizing

To successfully deploy a production-ready LiveKit instance on a Virtual Private Server (VPS), your environment should meet the following minimum specifications:

1. Hardware Requirements

CPU: 2 vCPUs minimum (Compute-optimized instances are preferred as network packet handling is CPU-bound).
RAM: 4 GB or higher.
Network: 1 Gbps port with unmetered or high bandwidth allocation. High packet-per-second (PPS) performance is critical.
OS: Ubuntu 22.04 LTS or Ubuntu 24.04 LTS.

2. Networking & Domain Prerequisites

A fully qualified domain name (FQDN) pointing to your VPS public IP address (e.g., livekit.yourdomain.com).
Open ports in your VPS firewall / Security Groups:
- 80/tcp and 443/tcp (for HTTP/HTTPS TLS validation and signaling).
- 7881/tcp (for LiveKit internal turn/signal fallback).
- 50000-60000/udp (for WebRTC media transmission - crucial for SFU operations).
- 3478/tcp & udp (for STUN/TURN server operation).

Step-by-Step Deployment Guide

We will use the official automated installation method via Docker and Caddy, which configures automated Let's Encrypt SSL certificates out-of-the-box. This ensures secure HTTPS and WSS (WebSocket Secure) connections required by modern browsers.

Step 1: System Preparation and Firewall Configuration

Connect to your VPS via SSH and update the system packages:

sudo apt update && sudo apt upgrade -y

Next, configure the Uncomplicated Firewall (UFW) to allow necessary traffic while blocking unauthorized access:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 7881/tcp
sudo ufw allow 50000:60000/udp
sudo ufw enable

Step 2: Generating the LiveKit Deployment Configuration

LiveKit provides a convenient deployment generation tool. Run the setup wizard using Docker by executing:

docker run --rm -it -v $PWD:/output livekit/generate

During the interactive prompt, provide the following parameters:

Domain Name: Enter your FQDN (e.g., livekit.yourdomain.com).
LiveKit Version: Select the latest stable release.
Features: Enable Turn server if your users are behind strict corporate firewalls.
SSL Configuration: Choose Let's Encrypt for automatic certificate management.

This script generates a directory structure containing livekit.yaml (the primary configuration file), docker-compose.yaml, and a startup script.

Step 3: Reviewing the Configuration Files

Verify your livekit.yaml to ensure keys and parameters are correctly populated:

cat livekit.yaml

The configuration file contains your api_key and api_secret. Secure these credentials safely; they are used by your backend application to generate access tokens for clients wishing to join live rooms.

Step 4: Launching the SFU Server

Navigate to the generated directory and run the initialization script to pull the Docker images and spin up the containers:

sudo ./run_script.sh

To verify that all services (LiveKit, Caddy, and Turn) are running smoothly, execute:

docker compose ps

Optimizing the Linux Kernel for High-Throughput Media

By default, Linux kernel networking parameters are optimized for general-purpose web servers, not high-frequency UDP packet routing. To prevent packet loss under high concurrent user loads, append the following configurations to /etc/sysctl.conf:

# Increase maximum network buffer sizes
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216

# Increase the maximum number of open files
fs.file-max = 2097152

Apply the changes instantly using: sudo sysctl -p.

Integrating with Web and Mobile Client SDKs

With the server infrastructure live, connecting client applications is straightforward using LiveKit’s ecosystem of official SDKs (supporting JavaScript/TypeScript, React, Flutter, Swift, Kotlin, and Unity).

The Token Generation Flow

Clients cannot connect directly without authorization. Your backend application must issue a signed JWT (JSON Web Token) containing the api_key and api_secret. Below is a conceptual example using Node.js:

import { AccessToken } from 'livekit-server-sdk';

const at = new AccessToken('YOUR_API_KEY', 'YOUR_API_SECRET', {
identity: 'user_id_123',
});
at.addGrant({ roomJoin: true, room: 'main_stage', canPublish: true, canSubscribe: true });
const token = await at.toJwt();

Connecting from the Client Side

Using the official frontend JavaScript SDK, connecting to your self-hosted VPS instance requires only a few lines of code:

import { Room } from 'livekit-client';

const url = 'wss://livekit.yourdomain.com';

const room = new Room();
await room.connect(url, token);
console.log('Connected to sub-second interactive stream room:', room.name);

// Publish local camera and microphone tracks
await room.localParticipant.enableCameraAndMicrophone();

Monitoring and Conclusion

Building a low-latency infrastructure is only half the battle; maintaining observability is crucial. LiveKit exposes production-grade metrics natively compatible with Prometheus and Grafana. By monitoring metrics such as room_duration_seconds, track_publish_attempts_total, and connection drop-rates, operations teams can dynamically scale infrastructure before users encounter performance degradation.

By deploying LiveKit SFU on a dedicated VPS, you eliminate high-cost per-minute third-party SaaS pricing while gaining complete sovereignty over your data and video delivery pipeline. You now possess a hardened infrastructure capable of delivering rich, interactive video experiences with sub-second latency across both web and mobile environments.

Deploying LiveKit SFU on a VPS: Building a Sub-Second Latency Interactive Video Streaming Infrastructure for Web and Mobile Apps