Cloud Overview

brūhi Cloud is a self-hosted, multi-station broadcast platform. DJs broadcast from any browser using their microphone; no software installation required on the operator’s machine.

Architecture

Browser (DJ)
    |  WebRTC audio (RTP bridge)
    v
GStreamer Ingest  ←→  FastAPI Backend (Python 3.11)
    |                         |
    v                         v
brūhi-audio Rust Engine     SvelteKit Web Dashboard
(per-station instance)     (multi-DJ studio workspace)
    |
    v
Icecast Output / External Stream Ingest

Components

Component	Technology	Purpose
API server	FastAPI (Python 3.11)	REST API, modular routes, station control locks
Web dashboard	SvelteKit + TypeScript	Multi-DJ UI (decks, mixer, soundboard, library)
Audio ingest	GStreamer + aiortc	WebRTC → RTP pipeline for browser microphone
Stream processor	brūhi-audio (Rust)	Native audio mixing, fallback chain, Icecast push
Media storage	S3 Media + Local Vol	Cloud S3 bucket & local volume audio library
Database	SQLite (`BRUHI_DB`)	Single consolidated DB (`/app/data/bruhi.db`)
Container	Docker Compose	Containerized app, Icecast, & optional Caddy

Multi-Station Model

Each station is an independent broadcast unit:

Its own bruhi-audio Rust engine runner (BRUHI_AUDIO_API daemon)
Its own Icecast mountpoint (/station-N.mp3)
Its own harbor port (HTTP ingest)
Its own control session locking & station management APIs
Its own playlist, automation rules, and output configuration

Multiple DJs can broadcast to different stations simultaneously from the same brūhi Cloud instance.

Port Allocation per Station

For station N (where N starts at 1):

Service	Port / Formula	Example (Station 1)
API + Dashboard	`PORT` (8000)	8000
Icecast mount	`${ICECAST_HOST_PORT:-8010}` / `/station-N.mp3`	`http://localhost:8010/station-1.mp3`
Harbor (HTTP ingest)	8100 + N − 1	8100

Signal Flow

Each station has a priority-based fallback chain:

1. Live WebRTC stream (DJ's browser mic via GStreamer RTP)
2. Live harbor input (HTTP push from external encoder)
3. Scheduled playlist (API & DB managed playout queue)
4. Silence (automatic — prevents stream interruption)

The highest available source is always used. When a DJ disconnects, the station automatically falls back to the scheduled playlist within one frame (~40 ms).

Web Dashboard

The brūhi Cloud web dashboard provides complete broadcast controls adapted for a browser environment:

Feature	Available
Setup Wizard & License Activation	Yes (first-run owner setup & license)
WebAuthn / Passkeys	Yes (secure passwordless logins)
Station Controller Lock	Yes (prevents concurrent DJ conflicts)
Dual-deck player with crossfader	Yes
Microphone input (WebRTC)	Yes
Soundboard / Cart Wall	Yes (64 pads with built-in defaults)
Content library + S3 media browser	Yes (full track deletion & metadata)
Playlists & smart playlists	Yes (harmonic key & repeat rules sync)
Broadcast outputs	Yes
PFL monitoring (Web Audio API)	Yes
DSP effects chain	Partial (browser-side EQ + compression)
Schedule	Yes (QuickAdd date input & rules)
MIDI mapping	No
brūhi Script	No

What’s Different from Desktop

Aspect	Desktop	Cloud
Audio source	Local OS audio devices	Browser WebRTC microphone
Audio engine	Rust audio engine (native)	`bruhi-audio` Rust engine container runner
Media storage	Local filesystem	Docker volume + S3 media
Database	Per-user SQLite	Consolidated SQLite (`/app/data/bruhi.db`)
Scheduling UI	Visual month & QuickAdd	API + Web QuickAdd schedule & rules
Multi-user	Single operator	Multi-DJ session locking & station management
Updates	In-app auto-update	`docker compose pull && docker compose up -d`

Getting Started

Self-Hosting — deploy with Docker Compose
Managed SaaS — fully managed cloud infrastructure
Multi-Station Setup — create and manage stations
Station Management — bruhi-audio engine config and station control lock
Authentication — owner setup, WebAuthn passkeys, license activation, and token security