# LiveKit server: self-hosting the WebRTC SFU behind voice and video agents

> The livekit/livekit repository is the Go server component of LiveKit, a Selective Forwarding Unit that moves audio, video and data between browsers, devices and AI agents. This article covers what it does, how to install and run it, and where the self-hosted server stops and the hosted service begins.

**livekit/livekit** — End-to-end realtime stack for connecting humans and AI

- Repository: https://github.com/livekit/livekit
- Website: https://docs.livekit.io
- Stars: 21,211 · Forks: 2,402
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/livekit-livekit

## What the livekit/livekit repository actually contains

This repository is the server, not the whole product. The README describes it as "a scalable, distributed WebRTC SFU that moves realtime audio, video, and data between people, devices, and AI models." An SFU receives media from each publisher and forwards selected streams to subscribers, rather than mixing them. That design keeps CPU cost per room low and preserves per-subscriber choice about which layers of a stream to receive, which is what makes simulcast and selective subscription possible.

The rest of the stack lives elsewhere. The SDKs, the Agents framework in Python and Node.js, and companion services are linked from the bottom of the README. If your goal is a voice agent rather than a media server, the repository's own banner points at livekit/agents instead. The server is the transport those agents connect through.

Who it is for: teams building realtime audio or video into an application and wanting to run the media path themselves, and teams wiring AI models into a live conversation where the model joins the room as a participant. The README states that people, devices and AI agents join the same room, with agent dispatch to route agents in automatically or on demand. That single-room model is the organising idea of the whole project.

## How the SFU moves media and data

The server is written in Go on top of Pion WebRTC, per the README and the go.mod dependencies, which list pion/webrtc, pion/ice, pion/dtls, pion/rtp and pion/turn. Those packages map onto the layers you would expect: ICE for connectivity, DTLS for the transport handshake, RTP for media, TURN for relay when direct paths fail.

A participant connects over WebRTC, publishes tracks, and the server forwards them to other participants according to subscription rules. The README lists the controls built on top: speaker detection, simulcast, selective subscription, moderation APIs, end-to-end encryption, SVC codecs (VP9 and AV1), data tracks, telephony over SIP, and webhooks. Authentication is JWT based. Connectivity is described as UDP, TCP and TURN.

For anything beyond one node, the architecture becomes distributed. The README links a distributed and multi-region guide, and go.mod includes the Redis client, which is the coordination layer for multi-node rooms. The practical consequence: a single-server deployment is a single binary with a config file, while a multi-region deployment is a system you operate, with Redis, node discovery and region routing to keep working. The README does not document rollback or downgrade behaviour for either case.

## Installing the LiveKit server and running a first room

The README gives three install paths. On macOS it is a Homebrew formula; on Linux it is a shell installer served from get.livekit.io; on Windows it points at the releases page. The README also recommends installing the LiveKit CLI alongside the server, because the CLI creates tokens, calls server APIs and generates test traffic.

On macOS:

```bash
brew install livekit
```

On Linux:

```bash
curl -sSL https://get.livekit.io | bash
```

The README notes that piping a remote script into a shell is the documented method, so read install-livekit.sh in the repository first if that matters to your environment. For containers, the repository ships a Dockerfile that builds ./cmd/server from a pinned golang:1.26.7-alpine3.24 image and runs the resulting binary on alpine:3.24.1.

To start the server, the README gives a development command:

```bash
livekit-server --dev
```

According to the README, --dev uses a placeholder API key and secret. That is convenient for a laptop and unacceptable in production, so treat the dev key as a local-only default. For a real deployment the repository includes config-sample.yaml at the top level; that file, not the README, is where the full set of keys lives. The README does not walk through a production config.

With the server running, the CLI is the shortest path to a working room: it can create an access token and join. The README does not print the exact CLI subcommand for that flow, so check the livekit-cli repository rather than guessing flags. What you should see after joining is your own participant in the room, with the server logging the connection.

## Where self-hosting the SFU gets hard

The install story is easy and the operations story is not, and the README is honest about the split only by omission. The server needs reachable UDP and TCP ports plus TURN for clients behind restrictive networks. It needs TLS in front of the signaling endpoint for browsers to connect at all. It needs a JWT issuer, which in practice means your application server minting tokens with the same API key and secret the SFU was configured with. None of that is a defect; it is the shape of every WebRTC deployment. It does mean "single binary" describes the artifact, not the work.

Scaling past one node is a second step. The README links the distributed guide and go.mod pulls in the Redis client, so multi-node rooms depend on Redis being available and healthy. The README does not describe what happens to in-flight rooms when a node leaves or when Redis is unreachable.

The clearest wrong-tool case is a team that wants a managed runtime for voice agents. The banner at the top of the README directs that audience to LiveKit Agents and states that LiveKit Cloud handles deployment and observability. If you want the agents framework, model routing and dashboards without operating media infrastructure, the self-hosted server repository is the wrong starting point. It is also the wrong choice if you only need one-to-one calling inside a single data centre and already run a conferencing stack; adding an SFU is new infrastructure for a problem you may not have.

## LiveKit versus Pipecat: server or pipeline framework

The related searches pair LiveKit with Pipecat, and the comparison is worth stating precisely because they do not sit at the same layer. This repository is a media server: it forwards RTP between participants and exposes rooms, tracks, data channels and webhooks. Pipecat is a framework for composing voice and multimodal pipelines, where audio flows through speech recognition, a language model and speech synthesis in sequence.

The difference in approach shows up in where the audio goes. With LiveKit, the SFU is the meeting point and an agent process joins the room as a participant, which is what the README means when it says people, devices and AI agents join the same room. A pipeline framework instead owns the audio path itself and treats transport as an input. You can run a pipeline against LiveKit transport, and LiveKit's own Agents framework is the project's answer to that layer, which is why the README routes voice-AI readers to livekit/agents rather than to this repository.

So the choice is not LiveKit or Pipecat in the abstract. If you need many participants in a room with selective subscription, simulcast and SVC, the SFU is the component doing that work. If you need a linear STT to LLM to TTS pipeline and your transport is already decided, the pipeline framework is the component doing that work. Picking this repository commits you to operating WebRTC infrastructure.

## Licence, releases and the cost of staying current

LiveKit server is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, so attribution requirements apply to redistributions. The Dockerfile header repeats the Apache 2.0 notice. Apache-2.0 is permissive and includes a patent grant, which is generally the reason projects in this space choose it over MIT, but this is not legal advice and the NOTICE file is the thing to read before you ship a modified binary.

Release cadence is visible in the tags: v1.13.5 on 2026-07-31, v1.13.6 on 2026-08-26, and v1.13.7 on 2026-09-14, with the last push to master on 2026-09-19. The project is not archived. That rhythm implies upgrade work: patch releases arrive roughly monthly, and a server holding live rooms cannot be restarted casually. The repository also carries a CHANGELOG.md and a .goreleaser.yaml, and the Dockerfile pins its base image by digest with a comment that Renovate updates the tag and digest together. That pinning is a deliberate choice for reproducible builds and it also means base-image updates arrive as pull requests you have to act on.

The upgrade cost you should plan for is not the binary swap. It is that the client SDKs and the server share the livekit/protocol module, so server and SDK versions move together. The README does not document a compatibility matrix or a supported upgrade path between minor versions, and it does not document rollback. Verify both against the CHANGELOG before you pin a version in production.

## Conclusion

Adopt the self-hosted LiveKit server when you need the media path inside your own network or want to avoid a managed dependency, and you are prepared to run TURN, TLS termination, Redis for multi-node rooms, and a JWT issuer yourself. Do not adopt it if you want a single binary that also gives you the agents runtime, telephony and observability: the README points those at LiveKit Cloud and at separate repositories. Before committing, verify three things against your own deployment: that `livekit-server --dev` starts and a token from `livekit-cli` joins a room, that your network allows the UDP and TCP ports the SFU needs, and that the config keys in config-sample.yaml match the release you pinned.

## FAQ

### What is LiveKit used for?

It is used to move realtime audio, video and data between participants. The README describes the server as a scalable, distributed WebRTC SFU, and notes that people, devices and AI agents join the same room as participants, with agent dispatch to route agents in automatically or on demand.

### Which companies use LiveKit?

The README lists Salesforce, Nvidia, Oracle, SAP, Deutsche Telekom, Spotify, Tinder, Coursera, Headspace, Skydio, Retell, Decagon, Cresta and HeyGen among the companies it says run it in production, and states that LiveKit carries billions of calls a year.

### How do I install LiveKit server?

On macOS the README gives brew install livekit, on Linux it gives a curl command piping get.livekit.io into bash, and on Windows it points at the latest release download. The README also recommends installing the LiveKit CLI alongside the server.

### How do I use LiveKit locally?

The README's getting-started section says to start the server with livekit-server --dev, which uses a placeholder API key and secret. That mode is for development; the repository's config-sample.yaml is the reference for a real configuration.

### Is LiveKit completely free?

The server in this repository is Apache-2.0 licensed, so you can run it yourself without a licence fee. The README separately points at LiveKit Cloud for deployment and observability of agents, which is a hosted service rather than part of this repository.

### How do I install LiveKit CLI?

The README recommends installing the LiveKit CLI alongside the server and links the livekit/livekit-cli repository, but this repository's install section only covers the media server, so the CLI's own repository is where its install steps live.

## Sources

- [License: Apache-2.0](https://github.com/livekit/livekit/blob/master/LICENSE)
- [livekit/livekit on GitHub](https://github.com/livekit/livekit)
- [Project website](https://docs.livekit.io)
- [README](https://github.com/livekit/livekit/blob/master/README.md)
- [Releases](https://github.com/livekit/livekit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/livekit-livekit