StreamKit

Note

See More

The hosted demo is a public instance. Don’t use sensitive data.

Caution

StreamKit is pre-1.0 (v0.5.0). Breaking changes may still occur and the security model is still evolving. If you expose a StreamKit instance to other machines, read the Security guide first. If upgrading from an earlier version, check the release notes for breaking changes.

A quick look

Who is this for?

StreamKit is built for developers who need to process real-time media — whether you’re compositing live video with overlays, building voice features, or prototyping AI-powered audio/video pipelines.

What you can build

• Video compositing — Combine live video inputs with text/image overlays using the built-in compositor (PiP, z-ordering, crop/zoom, rotation), with CPU and GPU backends. Encoded via VP9 or AV1 for real-time transport, with a visual scene editor in the Web UI
• Live web surfaces — Render any web page (including WebGL) to video frames via the Servo browser engine and composite them into live streams as overlays or standalone sources
• Live transcription — Ingest audio via MoQ, run Whisper or SenseVoice STT, stream transcription updates to clients
• Voice agents — TTS-powered bots using Kokoro, Piper, or Matcha that respond to audio input
• Real-time translation — Bilingual streams with live subtitles using NLLB or Helsinki models
• Audio processing — Mixing, gain control, format conversion, encoding/decoding pipelines
• Content analysis — VAD for speech detection, keyword spotting, or custom safety filters

What it is

Server

A single binary (skit) that serves the web UI and exposes an HTTP API and a WebSocket endpoint to create and manage pipelines.

Pipelines

Pipelines are directed acyclic graphs (DAGs) of nodes. You can author them in the web UI or as YAML.

Execution

Run pipelines as request/response batch jobs (HTTP) or as long-lived sessions you can inspect and update while they run (WebSocket).

Extensions

Add nodes via plugins (plugin::native::* or plugin::wasm::*) or embed JavaScript logic with core::script (with allowlists and limits).

Quick Example

Run the server (Docker):

TAG=v0.5.0 # replace with the latest release tag
docker run --rm \
  -p 127.0.0.1:4545:4545/tcp \
  -p 127.0.0.1:4545:4545/udp \
  ghcr.io/streamer45/streamkit:${TAG} \
  skit serve

Then open http://localhost:4545 to access the web UI.

Caution

StreamKit ships with built-in authentication (auto-enabled on non-loopback binds). Do not disable auth when exposing it beyond localhost; follow the Authentication and Security guides.

Note

Some sample pipelines depend on models like Whisper (STT), Kokoro (TTS), and NLLB (translation). The official Docker images keep those out of the base image; mount them when needed. Some models may have restrictive licenses (e.g. NLLB is CC-BY-NC); review model licenses before production use. See Docker Deployment and Plugins Reference for details.

Tip

Next:

• Follow the Quick Start to run your first pipeline end-to-end.
• Explore the web UI guide and Creating Pipelines when you’re ready to build your own graphs.

Try it from your terminal

No install required — these hit a public instance of the speech gateway example, a thin HTTP front-end over StreamKit oneshot pipelines (Kokoro TTS and Whisper STT).

Text to speech (returns Opus audio, piped straight to ffplay):

curl -d 'Hello from StreamKit' https://tts.streamkit.dev | ffplay -nodisp -autoexit -

Speech to text — pipe the synthesized audio straight back into STT (no local file needed) and get back newline-delimited JSON:

curl -fsSd 'StreamKit transcribes speech' https://tts.streamkit.dev | curl -fsS --data-binary @- https://stt.streamkit.dev

Note

tts.streamkit.dev and stt.streamkit.dev are a free, best-effort public demo with no SLA — they may be slow, rate-limited, or offline at any time, and usage is monitored for abuse. Don’t send anything sensitive. To run your own, see examples/speech-gateway.

Execution modes

StreamKit supports two pipeline execution modes:

• Oneshot: stateless batch processing via HTTP (POST /api/v1/process). Good for request/response workflows.
• Dynamic: long-running sessions you can inspect and reconfigure at runtime (web UI + WebSocket).

Dynamic sessions use MoQ (Media over QUIC) over WebTransport (QUIC/UDP) for real-time media transport. This is why the Docker example publishes both TCP and UDP on port 4545.

WebSocket is currently the control plane (sessions, graph edits, and telemetry). WebSocket transport nodes for media are being considered for a future release.

See:

• HTTP API
• WebSocket API
• Node Reference: transport::moq::peer
• samples/pipelines/