Self-hosting Open Live

Guide · September 2026 · 13 min read

Open Live is open source and you can run the whole thing yourself without paying us anything. This guide covers what the system is made of and under which licences, how to stand it up, every environment variable that matters, the one security decision self-hosting hands you, and an honest account of what you take on. It is written so you can make the build-or-buy call on real detail rather than on a marketing page.

What it is made of

Strom carries both LICENSE-MIT and LICENSE-APACHE, the usual Rust dual-licence, so you may take it under either. Do not repeat the shorthand that it is Apache-only; that is what GitHub's single-licence field displays, not what the repository grants.

Requirements

• pnpm 10.33 or later, corroborated by packageManager: pnpm@10.33.0 in package.json. For Node, both readmes say 23 or later, but package.json declares no engines field and pins @types/node: ^22.15.3, so 23 rests on the readme alone. Treat it as the stated minimum rather than an enforced one, and check package.json before provisioning.
• A CouchDB instance, local or remote.
• A Strom instance the API server can reach. Strom is where the GPU requirement lives, not in the API server.

Standing it up locally

The API server repository ships a reference docker-compose.yml that brings up CouchDB 3 alongside open-live, which is the fastest way to see the thing run. From source:

pnpm install
cp .env.example .env
# fill in the values, then
pnpm dev        # hot reload
pnpm typecheck  # type-check without emitting
pnpm build      # compile to dist/
pnpm start      # run the compiled server

The REST API is documented in docs/openapi.yaml and served from the running instance at /documentation. The WebSocket controller channel has its own document in the repository, covering authentication, inbound message types and outbound broadcasts.

Configuration

Read from src/config.ts and src/main.ts rather than from the readme, which is stale on several of these.

Authentication is the decision self-hosting hands you

The project does not leave this to chance, and the behaviour is worth knowing exactly. With NODE_ENV=production and no API_KEY, the server refuses to start unless TRUST_EXTERNAL_AUTH=true declares that a trusted layer in front is handling it. Outside production it logs a prominent warning instead. The reference docker-compose.yml will not bring the stack up without a key either.

The reasoning behind that pair is worth borrowing: the deployment tier and the authentication architecture are different questions, so NODE_ENV alone cannot stand in for the second one. On Open Source Cloud the reverse proxy authenticates every request before it reaches the API, which is the case TRUST_EXTERNAL_AUTH exists for. Self-hosted, that proxy is the part you are replacing.

Generate a real key rather than inventing one:

openssl rand -base64 32

HTTP clients send it as Authorization: Bearer <API_KEY>. Note that /health, /ready and /api/v1/status stay exempt even when the key is set, so your probes keep working.

new WebSocket(url, ["openlive.bearer", `openlive.bearer.${apiKey}`])

Pointing the studio at your backend

The studio reads one setting, and it is not a VITE_ variable. vite.config.ts sets envPrefix: ['OPEN_LIVE_'], which replaces Vite's default VITE_ prefix rather than adding to it, so a VITE_-prefixed variable is never exposed to the bundle at all. The variable is OPEN_LIVE_URL, and its default is http://localhost:3000.

window._env_?.OPEN_LIVE_URL || import.meta.env.OPEN_LIVE_URL || "http://localhost:3000"

If the studio is talking to the wrong backend, check env-config.js in the served directory before you reach for a rebuild. Note also that docker-entrypoint.sh requires jq and fails closed without it, deliberately, rather than falling back to manual escaping.

Kubernetes: what you get, and what you do not

The product is described on this site as deployable on any CNCF-conformant Kubernetes cluster. The repositories themselves say only "any Kubernetes cluster". It is worth being precise about what the repositories actually ship, because it is not a chart.

• You get: Dockerfiles for open-live, the studio and Strom, a reference docker-compose.yml for local work, and an nginx template for serving the studio.
• You do not get: a published Helm chart or ready-made Kubernetes manifests. Writing those is your side of the line.

The useful reference is the topology Open Source Cloud itself runs, because it is documented and it works: CouchDB (apache-couchdb), Strom (eyevinn-strom), and a parameter store (eyevinn-app-config-svc with valkey) injecting environment variables at runtime so no .env file sits on the server. Four services, not one, and the parameter store is the piece people forget when they plan this as a two-container deployment.

What you are taking on

The honest summary: the API server and the studio are ordinary Node services and are not hard to run. Strom and the GPU host are the real work, and so is being the person who fixes a pipeline at 19:55 on a Saturday.

Pre-production checklist

• API_KEY is set, or TRUST_EXTERNAL_AUTH is set and something in front genuinely authenticates. Verify from outside your network, not from a machine on it.
• CORS_ORIGIN matches the origin the studio is actually served from.
• OPEN_LIVE_URL is set in the studio's environment and env-config.js in the served directory carries the value you expect.
• CouchDB has backups, and a restore has been rehearsed rather than assumed.
• You have read the SRT passphrase rotation runbook before you need it.
• The GPU host has been load-tested at your real source count, not with two test feeds.
• Someone is named as on-call for the pipeline during a show, and it is not the person directing it.