One binary. Explicit modules.

Build a node from the inputs it accepts, the outputs it serves and the runtime features it needs.

Composition model

Every process reads one strict JSONC document. The input tree decides how media enters. The output tree decides where that media goes. server, transcode and webhook configure the shared runtime around those paths.

A node can ingest locally and serve HLS, LL-HLS or WebRTC, pull from another node only when an LL-HLS or WHEP viewer asks, record and publish to object storage, or combine those capabilities. Omitted modules do not start.

Private alpha: configuration is intentionally allowed to change. Use the guide that matches the binary version you deploy.

Guide structure

First run

Start a node

Run one container, push an SRT stream, check health and open HLS.

container + minimal JSONC

input.*

Bring media in

Accept SRT publishers, start managed source pulls or pull from an upstream node on demand.

push + pull + cascade

output.*

Send media out

Serve HLS, LL-HLS and WebRTC, retain recordings, publish to S3 or route normalized SRT onward.

HTTP + WHEP + recording + SRT

shared runtime

Control and observe

Separate media and operational listeners, inspect status, expose metrics and enable bounded repair or webhooks.

server + transcode + webhook

Common shapes

Standalone delivery: SRT push or managed pull input with HLS, LL-HLS, WebRTC and optional recording outputs in one process.
Cache-through delivery: Local inputs and cascade input share LL-HLS and WHEP surfaces. A local stream wins; only an absent stream starts the upstream pull.
Distribution node: Cascade input and cascade output can run together. Registry read and write use distinct key prefixes to avoid self-reference.

Start a node