Overview

Relevant source files

• .github/banner_dark.png
• .github/banner_light.png
• CHANGELOG.md
• README.md
• bootstrap.sh
• go.mod
• go.sum
• magefile.go
• tools/tools.go
• version/version.go

This wiki documents the LiveKit server codebase, a production-grade WebRTC Selective Forwarding Unit (SFU) written in Go. The server enables scalable, real-time video, audio, and data communication for multi-user applications.

Scope: This page provides a high-level introduction to the server's architecture, core components, and operational modes. For detailed subsystem documentation, see System Architecture Overview and Key Technologies and Dependencies.

What is LiveKit Server

LiveKit server is a WebRTC SFU that routes media streams between participants without transcoding. Written in Go go.mod1-3 and built on the Pion WebRTC stack go.mod42 it implements a selective forwarding architecture where each participant's media is received once and selectively forwarded to subscribers based on bandwidth and subscription preferences.

Core Capabilities:

• Multi-user conferencing: Room-based sessions with participants publishing and subscribing to tracks.
• Adaptive streaming: Dynamic layer selection (simulcast/SVC) and congestion control README.md33-40
• Distributed operation: Single-node or multi-node deployments with Redis-based coordination README.md42
• Data Tracks: Support for reliable and lossy data transmission, enabled by default in version 1.11.0 CHANGELOG.md7-21
• Extensibility: Egress (recording), Ingress (RTMP/WHIP), and Agent (AI participant) integrations README.md55-60

Entry Point: The main server logic is coordinated through the LivekitServer structure, which manages services, listeners, and the signaling stack.

Sources: README.md11-43 go.mod1-42 CHANGELOG.md5-21 version/version.go17

System Architecture

LiveKit server is organized into functional layers that bridge high-level API requests to low-level media forwarding.

Code Entity Relationship Diagram

This diagram maps natural language concepts to the specific Go entities and files that implement them.

Layer Responsibilities:

1. Service APIs: Client-facing interfaces for signaling (WebSocket) and management (Twirp) go.mod50
2. Routing & Distribution: Abstracts node selection and routes participants via the Router interface.
3. Room Management: RoomManager orchestrates the lifecycle of Room instances on a local node.
4. RTC Core: Manages individual participant state, peer connections, and track subscriptions.
5. Media Processing (SFU): Handles packet ingress, adaptive forwarding logic, and quality scoring. Recent updates include specialized managers for data tracks like UpDataTrackManager CHANGELOG.md13

Sources: README.md26-43 CHANGELOG.md12-14 go.mod25-50

Core Components

LivekitServer

The top-level server structure initialized using Wire dependency injection go.mod16 It manages the HTTP servers for APIs and the SignalServer for WebRTC signaling.

RoomManager

The central orchestrator on a node. It maintains the active room sessions and provides helpers for session lookup and participant routing.

Room

Represents an active multi-user session. It manages a collection of participants and coordinates track metadata and state synchronization.

For details on how these components interact, see System Architecture Overview.

Sources: go.mod16 README.md11-16

Configuration System

LiveKit uses a hierarchical configuration system:

1. Defaults: Hardcoded values within the server binary.
2. YAML: Configuration files loaded at startup go.mod59
3. CLI/Env: Overrides provided at runtime via urfave/cli/v3 go.mod149

The configuration covers networking, Redis for distribution, SFU parameters, and TURN server settings. Recent additions include options for forcing simulcast codecs and requiring media sections during join CHANGELOG.md59-125

Sources: go.mod149 go.mod59 CHANGELOG.md59-125

Deployment Modes

LiveKit's behavior changes based on the presence of Redis in the configuration.

Standalone vs Distributed

The server is wired differently depending on whether Redis is utilized for state and routing.

• Standalone: Uses local in-memory implementations for routing and storage. Ideal for development and small-scale use.
• Distributed: Uses Redis for cross-node signaling and state persistence go.mod45 Enables horizontal scaling where any node can route signaling to the node hosting a specific room using the Router abstraction.

Sources: go.mod45 README.md42

Key Technologies

The server relies on several critical libraries:

• Pion WebRTC: The underlying stack for WebRTC protocols go.mod42
• PSRPC: A custom Pub/Sub RPC system for inter-node communication go.mod25
• Redis: Used for state synchronization and as a message bus go.mod45
• Twirp: Used for the Room and Participant management APIs go.mod50
• Wire: Compile-time dependency injection go.mod16
• Mage: Build system used for generating code and building binaries magefile.go1-77

For a full list and technical details, see Key Technologies and Dependencies.

Sources: go.mod5-61 magefile.go1-77 version/version.go17

---

This page is a high-level entry point. Detailed technical specifications are available in the sub-pages.