LiveKit

LiveKit has four nouns that appear in every API.

A client opens two connections to the server: a WebSocket for signalling (join, publish, subscribe, mute, metadata, data) on the HTTP port, and a WebRTC transport pair for media and data. LiveKit uses a publisher peer connection to send and a subscriber peer connection to receive, so a track added on one side never needs a renegotiation of the other, which avoids the glare problem that perfect negotiation has to solve in a mesh.

DTLS-SRTP is mandatory in WebRTC, so every hop is encrypted, but the hop ends at the SFU: the server decrypts and re-encrypts the media it forwards. That is "encrypted in transit" and not "end-to-end"; the end-to-end option is covered in the encryption section below and on End-to-End Encryption.

The server is a single static binary distributed as the livekit/livekit-server image. Pin a tag instead of latest: the tag v1.13.10 used here is the release of 2026-10-14. A development setup needs one configuration file, one API key pair and a set of published ports.

The key under keys is the API key and its value is the API secret. Use at least 32 characters for the secret and never reuse the placeholder from this page. Redis is optional for a single node; it is included here because egress and ingress find the server through it, and it is also what lets several LiveKit nodes form a cluster.

Source: LiveKit docs: Running LiveKit locally and config-sample.yaml in the livekit repository. The ports entries of the page are the unmodified defaults (7880, 7881 and a UDP range); the example’s own range of thirty UDP ports is enough for fifteen participants because each participant uses two ports.

A LiveKit server never authenticates users: it trusts a signed JWT issued by your backend with the API secret. The token carries the participant identity and a video grant describing what that participant may do. The browser asks Huddle’s backend for a token after the user logs in; the API secret never reaches the browser.

Source: LiveKit docs: Authentication, tokens and LiveKit server SDK for JavaScript reference. A real endpoint authenticates the caller first (see Authentication and Authorization) and derives identity, the room and the host flag from that session, not from query parameters as this demo does.

The grants that matter for a videoconference:

The token also carries attributes (string key-value pairs visible to everyone), metadata and, since agents, a roomConfig that applies only when the token creates the room. When no TTL is given the SDKs default to six hours; a short TTL (ten minutes here) is the revocation mechanism on a self-hosted server, because tokens cannot be revoked there. Expiry applies to the initial connection; the server issues refreshed tokens to connected clients so reconnects keep working. On LiveKit Cloud, removing a participant or changing permissions also revokes the old token for ten minutes.

livekit-client is a TypeScript library for the browser (and React Native, with a separate package for the native WebRTC layer). Its central class is Room. The sequence is always the same: create a Room with options, register event handlers, connect(url, token), then publish.

Source: LiveKit client SDK for JavaScript reference and LiveKit docs: Data messages. The UMD bundle is served from node_modules/livekit-client/dist/livekit-client.umd.js; with a bundler use import { Room, RoomEvent } from 'livekit-client'. Two pages opened in one Chrome with fake devices each ended with the other’s audio and video tracks subscribed and live, the chat message from alice arrived at bob with the topic chat, and the active-speaker event fired for the synthetic beep of the fake microphone.

An SFU does not transcode, so quality adaptation means choosing which encoding to forward. LiveKit’s defaults already do the right thing for a meeting; the options exist to tune it.

Statistics (getRTCStatsReport() of a local or remote track, and the connection-quality event RoomEvent.ConnectionQualityChanged) feed the quality indicator described on Stats, Quality and Bandwidth.

The server notifies your backend of room events with signed HTTP POSTs. The signature is an Authorization header holding a JWT whose claim is the SHA-256 hash of the exact request body, so the body must be passed to the receiver as the raw text before any JSON parsing.

Source: LiveKit docs: Webhooks and the WebhookReceiver class of the server SDK. Joining a room with two browsers produced room_started, participant_joined and track_published lines for each participant, and a request with a forged Authorization header was rejected with 401. Events also exist for track_unpublished, participant_left, room_finished, egress_started, egress_updated, egress_ended and ingress_started/ingress_ended. Webhooks can be delivered more than once and out of order, so handlers must be idempotent.

Because the SFU decrypts SRTP, a compromised or curious server can see the media. LiveKit’s E2EE adds a second layer: the sender encrypts each encoded frame with a key the server never has (the SFrame approach standardised as RFC 9605), and the receivers decrypt after the SFU has forwarded it. The browser hook is an encoded transform; LiveKit runs it in a Web Worker that you supply, which is also why the SDK ships livekit-client.e2ee.worker.js. Chrome’s older createEncodedStreams() and the standard RTCRtpScriptTransform are both handled by the SDK, so the application does not choose between them. The cryptographic and key-management background is on End-to-End Encryption.

Source: LiveKit docs: End-to-end encryption. In the verification run the worker was served as a plain script (new Worker('/livekit-client.e2ee.worker.js')) and both pages reported isEncrypted for the other participant and subscribed to its tracks; the option is named encryption in livekit-client 2.23.0, while the earlier name e2ee is deprecated but still accepted.

What E2EE does and does not cover:

@livekit/components-react provides a context-based UI layer on top of livekit-client. It requires React 18 or later and livekit-client 2.20.1 or later as peer dependencies, and ships its CSS in @livekit/components-styles.

Source: LiveKit docs: React components reference and components-js on GitHub. The file compiles without errors under tsc --strict against @livekit/components-react 2.9.24, livekit-client 2.23.0 and React 19.

The pieces, from highest to lowest level:

With Next.js, create the token in a route handler or server action and render HuddleRoom in a client component.

Recording happens on the server through a separate service, livekit/egress, which joins the room as a hidden recorder, receives media like any subscriber and writes it with GStreamer. It finds the LiveKit server through Redis and is started through the server API with the API key pair (a token with the roomRecord grant can also use it). The types:

Outputs are MP4 or OGG files, HLS segments and thumbnails to local disk or S3, GCS, Azure and compatible storage, and live RTMP streams to platforms that accept them. The file path template accepts variables such as {room_name} and {time}.

Source: LiveKit docs: Egress overview and LiveKit docs: Self-hosting egress. Running this against the egress container above for eight seconds produced an MP4 of about one megabyte whose reported duration was the recording length. The current egress documentation groups participant, track-composite and track requests under a generic StartEgress request with a media source; the helper methods used here belong to the same server SDK and remain available in 2.19.2. Egress needs the Linux SYS_ADMIN capability for Chrome and plenty of CPU for a room composite, and a recording must be stopped (or the room ended) for the file to be finalised: never kill the container mid-recording.

Ingress brings external media into a room: a broadcaster using OBS, a hardware encoder, a media file or an HLS URL appears as a participant. It supports RTMP(S), WHIP (RFC 9725), and pull from HTTP or SRT URLs. WHIP is the standardised HTTP signalling for WebRTC ingest: the encoder POSTs an SDP offer with Content-Type: application/sdp to the endpoint and receives 201 Created with the SDP answer and a Location header for the session; the same mechanism is explained on WHIP, WHEP and Live Streaming. WHEP, its playback counterpart, is still an Internet-Draft; LiveKit viewers receive the stream as a normal subscribed track instead.

Source: LiveKit docs: Ingress overview and RFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP). Against the ingress container the POST returned 201 with a Location of the form /w/<streamKey>/<resourceId>, ICE reached connected, and a third page that had joined the room received the track from the participant stage-camera. In that run the url field of the returned ingress was empty because whip_base_url was not set in the ingress configuration; set whip_base_url (and rtmp_base_url) to the public address so that info.url can be handed to the broadcaster. The ingress service needs its own UDP port for WHIP media (published as 41340 above), at least four CPU cores and four gigabytes of memory per instance, and the same Redis as the server. The stream key is a bearer credential: treat it like a password, and delete the ingress when the broadcast ends.

The SDK and API are identical; only the URL and credentials change. LiveKit Cloud is the managed service: you create a project, copy its URL (a wss:// address on the livekit.cloud domain) and API key pair, and use them where this page uses ws://localhost:7880 and the dev keys.

Source: LiveKit docs: LiveKit Cloud. A single self-hosted node is documented as suitable for roughly three thousand participants on a room, while Cloud lists no per-room limit; multi-node self-hosting is covered on Distributed setup and, for the network side, on Scaling WebRTC and TURN. Start on Cloud or on the Docker setup of this page, and keep all LiveKit URLs and keys in configuration so the switch is a deployment change.

Huddle has three media modes: a mesh for up to four participants, an SFU mode on mediasoup (see mediasoup) and this variant. The mapping between the hand-built SFU and LiveKit shows what the platform removes:

The flow of a Huddle LiveKit session is: the user logs in; the page asks /token for a token for room standup; the page connects with adaptiveStream and dynacast; a pre-join screen calls Room.prepareConnection and checks devices; the host’s token has roomAdmin; chat is a text stream on topic chat; hand raise is an attribute plus an RPC to the host; the host starts a track-composite egress; and a webinar viewer receives a token with canPublish: false. Huddle’s backend keeps only the token endpoint, the room-creation policy and the webhook receiver.