Introduction: The Shift Toward Self-Hosted Real-Time Communication

In the modern mobile application ecosystem, real-time communication (RTC) is no longer a luxury feature; it is a core user expectation. Whether you are building a collaborative enterprise tool, an interactive live fitness app, or a high-engagement social platform, integrating real-time voice and video is essential. However, relying on proprietary, third-party Platform-as-a-Service (PaaS) providers can quickly become cost-prohibitive as your user base scales.

This is where LiveKit enters the frame. LiveKit is an open-source, high-performance WebRTC ecosystem designed to simplify the complexities of real-time audio and video. By deploying LiveKit as a Selective Forwarding Unit (SFU) on your own Virtual Private Server (VPS), you can maintain complete control over your data infrastructure, achieve sub-100ms latency, and drastically reduce operational overhead. This comprehensive guide walks you through the architectural advantages of an SFU and provides a step-by-step production deployment strategy tailored for mobile application backends.

Understanding WebRTC Topologies: Mesh vs. MCU vs. SFU

Before diving into server configuration, it is critical to understand why an SFU is the ideal architecture for mobile applications. WebRTC connections generally operate under one of three main topologies:

Mesh Topology (Peer-to-Peer): Every participant connects directly to every other participant. While cost-effective for small groups, bandwidth and CPU consumption scale exponentially ($O(N^2)$), making it highly impractical for mobile devices with constrained battery life and fluctuating network conditions.
Multipoint Control Unit (MCU): The server receives media streams from all participants, decodes them, mixes them into a single video/audio stream, encodes it, and sends it back to each user. This minimizes client-side load but demands immense CPU power on the server, resulting in high infrastructure costs and increased latency.
Selective Forwarding Unit (SFU): The paradigm utilized by LiveKit. In an SFU architecture, each client uploads their media stream to the central server only once. The SFU acts as an intelligent router, forwarding those streams to all other connected participants without re-encoding the video.

"An SFU offers the perfect architectural compromise for mobile applications: it keeps client-side bandwidth and CPU usage low while maintaining exceptionally low server overhead and minimal latency."

Prerequisites and VPS Hardware Sizing Guide

To follow this guide, you will need a clean VPS running a modern Linux distribution (Ubuntu 22.04 LTS or Ubuntu 24.04 LTS is highly recommended). Because real-time media processing is network and CPU-intensive, your choice of VPS hardware is paramount.

Consider the following baseline sizing recommendations for a production-ready environment:

1. Small-Scale Deployment (Up to 100 concurrent users)

CPU: 2 vCPUs (Compute-optimized preferred)
RAM: 4 GB
Network: 1 Gbps port with unmetered or high egress bandwidth limits

2. Medium-Scale Deployment (Up to 1,000 concurrent users)

CPU: 4 to 8 vCPUs
RAM: 8 GB to 16 GB
Network: 1 Gbps to 2 Gbps dedicated port

Additionally, you must have a Fully Qualified Domain Name (FQDN) pointed to your VPS IP address (e.g., livekit.yourdomain.com) to generate valid SSL/TLS certificates, which are strictly required by WebRTC protocol standards.

Step 1: Network and Firewall Configuration

WebRTC requires open ports for signaling (over HTTP/WebSocket) and media streaming (over UDP). Properly configuring your system firewall is the first step to ensuring stable connections, especially across unpredictable mobile carrier networks (4G/5G).

Execute the following commands to configure the Uncomplicated Firewall (UFW) on Ubuntu:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 7880/tcp
sudo ufw allow 7881/tcp
sudo ufw allow 50000:60000/udp
sudo ufw enable

Here is a breakdown of what these ports handle within the LiveKit ecosystem:

Ports 80 & 443 (TCP): Used for Let's Encrypt automated SSL validation and secure HTTP/WebSocket signaling traffic.
Ports 7880 & 7881 (TCP): LiveKit internal signaling and health checks.
Ports 50000-60000 (UDP): The RTC media ports. This range handles the actual exchange of audio and video packets using RTP/SRTP protocols.

Step 2: Installing Docker and Docker Compose

The most efficient and maintainable way to run LiveKit in production is via containerization. Install Docker and the Docker Compose plugin using the official Docker repository scripts:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL [https://download.docker.com/linux/ubuntu/gpg](https://download.docker.com/linux/ubuntu/gpg) | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] [https://download.docker.com/linux/ubuntu](https://download.docker.com/linux/ubuntu) $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.6d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Step 3: Generating the LiveKit Configuration

LiveKit provides an official deployment generation tool that streamlines setting up system configurations, keys, and reverse proxy settings. Run the deployment utility using the following command:

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

The interactive CLI tool will prompt you for several details. Provide the configuration options below:

Domain Name: Enter your FQDN (e.g., livekit.yourdomain.com).
LiveKit Version: Select the latest stable release.
Primary Feature: Choose "LiveKit Server with built-in Turn/Stun".
SSL Configuration: Select "Let's Encrypt" for automated HTTPS management.

Once completed, the utility generates a directory containing your livekit.yaml configuration file and a docker-compose.yaml bundle. Let us review the critical components generated inside livekit.yaml:

port: 7880
bind_addresses: ["0.0.0.0"]
rtc:
  port_range_start: 50000
  port_range_end: 60000
  use_external_ip: true
keys:
  API_KEY_HERE: API_SECRET_HERE

Crucial Security Step: Note down the generated API_KEY and API_SECRET. Your application backend will use these credentials to generate secure Access Tokens for your mobile clients.

Step 4: Launching the Media Server Infrastructure

Navigate to the generated output directory and start the LiveKit container services in detached mode:

cd livekit-deploy
sudo docker compose up -d

Verify that your containers are running seamlessly and check the logs to ensure that Let's Encrypt successfully completed the TLS challenge:

sudo docker compose ps
sudo docker compose logs -f

Step 5: Optimizing Linux Kernel Parameters for Production WebRTC

By default, Linux kernel networking queues are optimized for standard web server workflows (such as serving static assets or light REST APIs). Real-time media streaming causes highly volatile spikes in UDP packet traffic. To prevent packet loss, which degrades audio and video quality, you must modify your VPS network stack settings.

Open your system configuration file: sudo nano /etc/sysctl.conf and append the following performance tuning directives at the bottom:

# Increase maximum OS receive and send buffer sizes for UDP
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
et.core.wmem_default=16777216

# Adjust maximum number of open files and file descriptors
fs.file-max=2097152

Apply the changes immediately without restarting the machine by running:

sudo sysctl -p

Connecting Your Mobile Applications to the Infrastructure

With your LiveKit SFU server configured and optimized, your mobile clients can now connect. LiveKit provides highly optimized native SDKs for Swift (iOS), Kotlin (Android), and cross-platform frameworks like Flutter and React Native.

The workflow for connecting mobile clients involves two distinct phases:

1. Server-Side Token Generation

Your mobile application should never store your master API_SECRET. Instead, when a mobile client wants to join a video or voice room, it sends a request to your application's secure backend API. Your backend uses the LiveKit Server SDK to mint a short-lived JSON Web Token (JWT) containing the room name and participant permissions.

2. Client-Side Connection Initialization

Using the native LiveKit SDK on the mobile device, passing the server URL (wss://livekit.yourdomain.com) and the fetched JWT token establishes a persistent, bi-directional connection over the configured WebRTC channels.

Conclusion

Building a self-hosted WebRTC SFU media infrastructure using LiveKit on a VPS empowers your development team to bypass the restrictive pricing models of commercial PaaS solutions while retaining end-to-end data ownership. By tuning your Linux network stack, properly wrapping communication protocols through open UDP ports, and abstracting client management through tokenization, you establish a production-grade backend ready to deliver ultra-low latency streaming and voice communication straight to your iOS and Android users.

Scaling Real-Time Video and Audio: How to Configure a VPS as a LiveKit WebRTC SFU Media Server for Mobile Apps