Bunryu (分流, "branching flow"): one live stream, many destinations.
Self-hosted restreaming server built for reliability, for live events that run for many hours. Take inputs over RTMP, SRT and bonded SRT, and forward each one to many RTMP/RTMPS/SRT destinations (YouTube, Facebook, Twitch, CDNs) from one Linux server. Watchdogs restart a failed output without affecting the others.
Who it's for: teams that run many live inputs and need each one forwarded to many destinations for hours, on a server they control. Who it isn't for: viewers' playback (no player, WebRTC or HLS delivery), hardware encoding, ARM or Windows hosts, or a hosted multistreaming service with accounts and billing (when not to use it).
Built on official SRS for ingest, goryu for bonded SRT ingress, and FFmpeg for outputs, with a Node.js + TypeScript control plane, web dashboard and REST API.
| Install | Try with Docker | Documentation |
|---|
The preview plays Hokusai's The Great Wave (public domain, The Met Open Access) animated for this screenshot. The outputs are simulated.
- Ingest over RTMP, SRT and bonded SRT, with stream-key authorization and passphrase-protected SRT.
- Forward each input to many RTMP, RTMPS or SRT destinations: no fixed limit, tested with 50 inputs and 500 outputs per server. Copy-mode (passthrough) outputs cost almost no CPU.
- Transcode a few outputs to 720p, 1080p or a rotated vertical feed for Shorts/Reels, and select audio tracks per output, including multi-track SRT outputs. Outputs that need the same encode share one FFmpeg, so ten 720p outputs cost one encode, not ten.
- Watch everything in a live dashboard: HLS preview, ffprobe media details, bitrates, host and per-process CPU/RAM/network charts, and copy-ready publish URLs, and it stays readable with 50 inputs and 500 outputs (measured).
- Stay reliable through long events: watchdogs, isolated outputs, safe restarts and post-incident evidence.
50 inputs and 500 outputs in one dashboard. The control plane, SRS and inputs are real; the outputs are simulated, so no FFmpeg load is shown (details).
A live event can't be restarted. Bunryu assumes something will go wrong (a destination stalls, an encoder drops, a process runs out of memory) and is built so the failure stays small, fixes itself where that is safe, and is explained afterwards.
Main Stage's publisher drops for 16 seconds. The other pipelines keep running, and the affected outputs recover by themselves when the input returns. The control plane, SRS and inputs are real; the outputs are simulated.
- Isolated: each output is its own FFmpeg process. A frozen, refusing or non-reading destination, a dropped input or a crashed FFmpeg doesn't touch the other outputs or pipelines.
- Bounded recovery: watchdogs restart stuck outputs with limits, so a bad destination can't cause a restart storm.
- Safe startup: SRS accepts publishes only once the control plane is ready, and a service restart or host reboot comes back from SQLite without manual steps.
- Accurate state: inputs and outputs don't stay "running" in the dashboard after a disconnect, crash or restart.
- Evidence: per-output History, rotated diagnostics, and incident write-ups of real failures and their fixes.
- Small and boring: no media code of our own. SRS, libsrt and FFmpeg do the media work, and the control plane is about 12,000 lines of TypeScript; it costs some efficiency (why).
These paths are exercised with fault-injection scenarios (a frozen destination, one that never reads, one that refuses connections, output churn, a publisher outage, an SRS crash, a CPU-saturated host and a soak with 50 healthy outputs). No software can promise that nothing fails: see Known issues and the supported capacity for what Bunryu does not cover.
Try it with Docker:
git clone https://github.com/live-miracles/bunryu
cd bunryu
BUNRYU_DASHBOARD_PASSWORD='choose-a-long-password' docker compose up -dOpen http://localhost:8080, log in with that password, create a pipeline and publish to the URL the dashboard shows. No camera? Publish a test card with FFmpeg.
Install on a server (Debian/Ubuntu, x86_64, systemd), the recommended setup for production:
sudo git clone https://github.com/live-miracles/bunryu /opt/bunryu
sudo BUNRYU_DASHBOARD_PASSWORD='choose-a-long-password' bash /opt/bunryu/scripts/server-install.shThe installer needs the initial dashboard password on a fresh install and never prints one. See Native install for firewall ports, updates and the SRT passphrase, and Remote access for reaching the dashboard securely.
- Getting started: Introduction · Docker · Native install · Comparison with alternatives
- Usage: Publishing · Outputs
- Operations: Security · Remote access · Configuration · Reliability · Known issues
- Reference: REST API · Development
Ask questions and share ideas in Discussions. Report bugs as issues.
MIT. SRS, goryu and FFmpeg are separate projects under their own licenses.