SDK + self-hosted workflow stack for LiveKit
Your infrastructure.
Your stack.
Per-speaker recording, speech moderation, durable server-side timers, and typed webhooks — shipped as one self-hosted stack on top of bundled LiveKit OSS. Deploy once, inspect everything, and extend any part of the system without a managed dependency.
One-time payment · No subscription · Secure checkout via Stripe
What's included
Everything the SDK + workflow stack ships with.
Per-speaker recording
Start and stop a LiveKit egress scoped to each speaker slot. Every speaker gets their own clip delivered to your S3 bucket — no room-level composites, individual files keyed by your slot ID.
Speech moderation
After each recording completes, the SDK extracts audio, transcribes via Google Speech-to-Text, and scores for toxicity using Cloud Natural Language. All on your Google Cloud account.
Server-side timer enforcement
Pass timerSeconds when a speaker starts. The SDK schedules a countdown server-side — when it fires, your onTimerExpired callback is called. No client trust required.
LiveKit included
The deployment package ships with standard LiveKit OSS, pre-configured for rooms, tokens, egress, and worker wiring. You deploy one stack with Docker Compose and own the full media layer from day one. No separate LiveKit setup, no managed service dependency, no Relay-hosted transport.
Signed webhooks
HMAC-SHA256 signed payloads with your own secret. Typed helpers for speaker.recording_ready, speaker.timer_expired, and moderation.speech_flag_raised.
Python + TypeScript
Two first-class packages with identical APIs. Drop the Python SDK into FastAPI or Django. Drop the TypeScript SDK into Express, Next.js, or any Node.js backend.
How it works
Four calls to go live.
This is not a thin wrapper over a hosted API. It is a source-included workflow layer that runs on your infrastructure alongside bundled LiveKit OSS. If you already have a speaker queue and room lifecycle in your app, it slots in at the video layer. The API is identical in Python and TypeScript.
Deploy the stack
docker compose up. LiveKit OSS, the Relay API, and all workers start together. No separate LiveKit setup — it's included and pre-wired.
Create rooms and issue tokens
relay.halls.create() spins up a room on your LiveKit server. relay.halls.joinToken() returns a signed JWT for each participant.
Start a speaker slot
Call relay.speakers.start() when a speaker is promoted. Pass slotId, timerSeconds, and an async callback. Egress starts and timer arms in one call.
End the slot — or let the timer fire
Call relay.speakers.end() manually, or let onTimerExpired handle it. The egress stops, the clip lands in S3, and speech moderation runs automatically.
LiveKit solves transport. This solves the workflow layer.
Rooms and streams are solved.
Everything above them isn't.
Any media server gives you a room. What your product actually needs — per-speaker recording, moderation, timing, and reliability — is a separate layer that most teams build on top of LiveKit or equivalent, get partially right, and maintain indefinitely.
Per-speaker recording
Room composites mix every speaker into one file. Splitting by individual means managing egress start/stop races, per-slot S3 delivery, and clip lifecycle tied to your room events — before you've written a line of product logic.
SDK: One call per speaker slot. Individual MP4s keyed by your slot ID, delivered straight to your S3 bucket. The lifecycle is handled.
Speech moderation
Toxicity detection means wiring transcription into your recording pipeline, pulling audio after each clip, scoring it, and emitting alerts — without missing a recording or blocking the room on slow API calls.
SDK: Transcription and toxicity scoring run automatically after each recording completes. Flagged clips emit a typed webhook. Nothing to wire up.
Server-side timer enforcement
Client timers drift, can be bypassed by network drops, and don't survive disconnects. Real enforcement means a durable server-side job that fires regardless of client state — and doesn't need trust in the browser.
SDK: Pass timerSeconds on start. The countdown runs server-side. onTimerExpired fires reliably — no client trust required.
Durable by default
Deploys, crashes, and restarts should not kill active timers or break in-flight speaker sessions. In-memory state disappears with the process — recovery logic is yours to build, or speakers get silently cut off.
SDK: The SDK supports Redis-backed timer persistence and startup restoration so countdowns survive process restarts and recover cleanly. A single restoreTimers() call re-arms everything.
Own the stack
Every line is yours to read, run, and change.
Most infrastructure products are black boxes you pay to keep running. This one ships with source. You can read how every subsystem works, debug it locally, and modify anything — today or two years from now.
The SDK is designed to be read, debugged, and modified.
LiveKit OSS ships bundled and pre-configured, but remains your deployment.
Each subsystem is isolated: recording, timers, moderation, webhooks, and storage.
You can run the stack as-is or replace parts over time.
Built to be extended
Replace any part of the system.
Each subsystem has a clear interface. You start with the defaults and swap them out as your requirements evolve.
Swap moderation providers. Start with Google Speech-to-Text + Natural Language, replace with your own pipeline later.
Bring your own storage. Use S3-compatible storage and keep clips in your own bucket.
Control timer durability. Use Redis persistence for restart-safe timers, or adapt the timer store to your own infra.
Own your event contract. Signed webhooks and typed events make it easy to plug into your own backend workflows.
Keep LiveKit standard. The bundled deployment uses LiveKit OSS as the media layer, so you are not locked into a proprietary transport.
Best fit
Who this is built for.
Structured speaking products
Debates, town halls, classrooms, pitch rooms, and AMAs — any format where speakers take turns and the session needs to be recorded, timed, and moderated.
Teams building on LiveKit
Teams using or considering LiveKit who do not want to spend weeks building recording orchestration, timer durability, and moderation plumbing.
Developers who want infra control
Teams who want to self-host, inspect the code, and keep long-term control of the stack — without a managed dependency in the critical path.
SDK vs. Relay hosted API
| Feature | Relay API | SDK |
|---|---|---|
| Per-speaker recording | ✗ Room composite only | ✓ |
| Speech toxicity detection | ✗ Not included | ✓ |
| Server-side timer enforcement | ✗ Client responsibility | ✓ |
| Runs on your infrastructure | ✗ Relay servers | ✓ |
| Data never leaves your stack | ✗ Processed by Relay | ✓ |
| Pricing model | Monthly subscription | ✓ One-time payment |
| No managed dependency | ✗ API dependency | ✓ |
| Source included | ✗ Closed | ✓ |
Pricing
One purchase gives you the complete self-hosted stack: Python SDK, TypeScript SDK, bundled LiveKit OSS deployment, recording/timer/moderation workers, tests, and integration examples.
No monthly SDK fee, no seat limits, no usage caps, and no managed dependency.
Runs on your infrastructure indefinitely. Source code included.
One-time payment · No subscription · Secure checkout via Stripe
Questions first? Email us
What's in the box
- Python SDK + TypeScript/Node.js SDK
- LiveKit OSS — bundled, pre-configured, no separate setup
- Docker Compose deployment recipe (LiveKit + egress + workers)
- Per-speaker recording pipeline
- Speech moderation (Google Speech-to-Text + Natural Language)
- Server-side timer enforcement with async callbacks
- Redis-backed timer persistence
- Webhook signing and typed event parsing
- Halls and token generation helpers
- Tests and integration examples
- Architecture documentation and deployment notes
- Example integration for structured speaking apps
- Support for setup questions
Updates and priority support available as an optional annual add-on.