DPTCloud
Back to articles
Technology Insight

Self-Hosting a WebRTC SFU Media Server with LiveKit: Scalable Voice/Video Infrastructure for Mobile Startups

May 26, 2026

Introduction: The Real-Time Communication Dilemma for Startups

In the modern mobile application ecosystem, integrating real-time voice and video capabilities is no longer a luxury—it is a core user expectation. Whether you are building an interactive EdTech platform, a telehealth solution, or a collaborative enterprise tool, seamless audio/video (AV) communication is paramount. However, startups frequently hit a strategic roadblock: the massive financial scaling walls of third-party Communication-as-a-Service (CPaaS) vendors.

While CPaaS providers offer rapid initial integration, their per-minute, per-user pricing models can decimate a startup's runway as user acquisition spikes. The alternative? Building a self-hosted WebRTC infrastructure. Historically, this meant wrestling with complex protocols like TURN/STUN, managing media routing architectures, and maintaining massive, monolithic media servers.

Enter LiveKit: a modern, open-source WebRTC ecosystem designed precisely to eliminate this complexity. By utilizing a Selective Forwarding Unit (SFU) architecture, LiveKit allows startups to host their own high-performance media servers on affordable Virtual Private Servers (VPS). This guide provides a production-grade blueprint for configuring a VPS into a robust LiveKit WebRTC SFU Media Server, optimized for mobile app clients.

Understanding the Architecture: Mesh vs. MCU vs. SFU

Before executing command-line configurations, it is critical to understand why LiveKit’s Selective Forwarding Unit (SFU) architecture is uniquely suited for mobile environments compared to traditional WebRTC topologies:

  • Mesh Network (Peer-to-Peer): Every participant connects directly to every other participant. While cost-effective, a 5-person call requires each mobile device to maintain 4 upstream and 4 downstream streams, rapidly draining the device's battery and exhausting mobile data bandwidth.
  • Multipoint Control Unit (MCU): The server receives all media streams, mixes them into a single video/audio stream, and sends it back to each participant. This saves client bandwidth but requires immense, cost-prohibitive CPU processing power on the server side.
  • Selective Forwarding Unit (SFU): Each participant uploads their media stream exactly once to the server. The SFU server then forwards that stream to all other participants without re-encoding it. This balances client performance with server efficiency, making it the industry standard for scalable applications.
LiveKit acts as an ultra-high-performance SFU written in Go, capable of routing thousands of concurrent video and audio tracks simultaneously on minimal hardware footprints.

Step 1: VPS Sizing and Prerequisites

For a production-grade LiveKit deployment serving mobile applications, your VPS provider (e.g., DigitalOcean, AWS EC2, Linode, or Vultr) must meet specific baseline requirements. WebRTC is highly sensitive to network jitter and packet loss, meaning network throughput and geographical proximity to your users are more critical than raw CPU core counts.

Minimum Recommended VPS Hardware Specs

  • CPU: 2 vCPUs (Dedicated CPU instances are highly recommended over shared/burstable cores to prevent audio stuttering).
  • RAM: 4 GB RAM.
  • Operating System: Ubuntu 22.04 LTS or Ubuntu 24.04 LTS.
  • Network: 1 Gbps outbound bandwidth limit, unmetered or high data transfer cap.

Domain and Networking Prerequisites

You must map a fully qualified domain name (FQDN) to your VPS IP address (e.g., livekit.yourstartup.com). Additionally, you must open specific ports on your firewall to allow real-time WebRTC media transit:

  • 80/TCP and 443/TCP: For HTTP/HTTPS traffic and TLS certification challenges.
  • 7880/TCP: LiveKit HTTP API and WebSocket signaling.
  • 7881/TCP: LiveKit Node-to-node communication (if scaling out).
  • 50000-60000/UDP: WebRTC media routing (crucial for actual video/audio data streams).

Step 2: Automated Deployment via LiveKit CLI

The LiveKit team provides an official deployment utility that automates Docker container configuration, Let's Encrypt SSL generation, and basic system optimizations. Connect to your VPS via SSH and run the installation script:

sudo curl -sSL [https://get.livekit.io/setup](https://get.livekit.io/setup) | bash

Once installed, initiate the setup wizard. This tool will prompt you for your target domain, generation of security keys, and auto-configuration of Turn/STUN settings:

livekit-cli generate-keys
./livekit-server setup

During the setup, ensure you choose the Docker Compose deployment method. The script generates a critical configuration file named livekit.yaml. Let us review the optimal configuration blocks for mobile performance.

Step 3: Optimizing the livekit.yaml Configuration

To support mobile applications operating on volatile cellular networks (4G LTE/5G), your SFU must be fine-tuned. Open your livekit.yaml configuration file and ensure the following keys are explicitly defined:port: 7880 bind_addresses: - "" rtc: tcp_port: 7881 udp_port_range: start: 50000 end: 60000 use_external_ip: true sticker_interval: 1 turn: enabled: true domain: livekit.yourstartup.com tls_port: 5349 udp_port: 3478 keys: YOUR_API_KEY: YOUR_API_SECRET

Why is the TURN server vital? In mobile environments, users are frequently behind symmetric NATs or strict corporate firewalls (e.g., coffee shop Wi-Fi). If a direct peer-to-SFU UDP connection fails, the integrated TURN server relays the traffic over TLS port 5349, ensuring your mobile app maintains a 100% connection success rate.

Step 4: Linux System Performance Tuning

By default, Linux environments limit the number of open file descriptors and network buffer sizes, which restricts a WebRTC server from handling maximum capacities. Execute the following commands to tune your kernel parameters:

Edit /etc/sysctl.conf and append these network stack optimizations:# Increase maximum number of open files fs.file-max = 2097152 # Maximize network receive/send buffer sizes for UDP net.core.rmem_max = 25165824 net.core.wmem_max = 25165824 net.core.rmem_default = 25165824 net.core.wmem_default = 25165824

Apply the changes immediately by executing: sudo sysctl -p.

Step 5: Connecting Your Mobile Application (iOS & Android)

With your VPS now functioning as a verified WebRTC SFU Media Server, your mobile backend must generate access tokens for client authentication. Clients should never communicate directly with LiveKit using the API Secret.

When a mobile user requests to join a video room, your backend authentication service generates a secure token using the LiveKit Server SDK (available in Node.js, Go, Python, and Ruby):

// Example utilizing Node.js Server SDK
import { AccessToken } from 'livekit-server-sdk';

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

Your mobile frontend app (built via LiveKit’s native Swift, Kotlin, Flutter, or React Native SDKs) receives this JWT token and establishes a connection directly to the server:

// Example workflow using LiveKit Swift SDK for iOS
let room = Room()
room.connect("[https://livekit.yourstartup.com:7880](https://livekit.yourstartup.com:7880)", token).then { room in
    print("Successfully connected to self-hosted SFU!")
    // Publish local camera and microphone tracks
    room.localParticipant.setCamera(enabled: true)
    room.localParticipant.setMicrophone(enabled: true)
}

Key Optimization Features for Mobile Clients

LiveKit stands out by handling volatile network transitions gracefully out of the box, provided you activate these features in your mobile client integration:

  • Simulcast: The mobile app uploads multiple quality layers (High, Medium, Low) of a video stream. If a remote viewer's connection degrades, the LiveKit SFU automatically drops their inbound stream to Low quality without impacting other high-speed viewers.
  • Adaptive Stream: LiveKit dynamically pauses video tracks that are not actively visible on the mobile user's viewport, conserving significant device CPU and bandwidth.
  • Connection Resiliency: If a mobile user switches from a Wi-Fi connection to a cellular 5G network, LiveKit automatically migrates the WebRTC session without dropping the ongoing call.

Conclusion

By hosting your own LiveKit SFU Media Server on a well-configured VPS, your startup establishes complete sovereignty over its communication data, eliminates unpredictable variable billing, and ensures maximum optimization for mobile users. As your platform scales, LiveKit's decentralized architecture allows you to easily transition from a single VPS to a distributed, multi-region cluster. You now have a production-ready, highly secure, and highly cost-effective real-time infrastructure tailored to support your business's growth.

Self-Hosting a WebRTC SFU Media Server with LiveKit: Scalable Voice/Video Infrastructure for Mobile Startups | DPTCloud