Your Minecraft server drives OBS. Die on stream and the scene cuts itself.
You get killed by a creeper. Before you have finished saying anything about it, OBS has already clipped the replay buffer, put "Kiosk01 died: creeper" on the overlay, cut to your death scene, and cut back six seconds later.
Nobody touched a hotkey. The server did it.
StreamBridge connects a Minecraft server to OBS Studio over obs-websocket v5 and turns what happens in game into scene switches, source and filter toggles, replay-buffer saves, recording control and text overlays.
Three things, and only one of them is a file you edit:
config/streambridge.json: which event, an
optional condition, a cooldown, and what to do./streambridge reload applies changes without restarting anything.
Every one of them is decided on the server. No player can trigger anything except through the events above, and every manual control checks your permission level first.
{player} died: {cause}Actions can be delayed: cut to a death scene now, cut back six seconds later, from one rule.
/streambridge dashboard, or right-click a Scene Remote that is not bound to
anything yet.
It lists the scenes OBS actually reports — not a list you had to type into a config first. Click one to switch to it. The scene that is live is marked. Next to each scene is a bind button, which writes that scene onto the Scene Remote in your hand.
On the right it lists your rules, each with the number of times it has fired, a click to test-fire it, and an on/off toggle for when a rule is being annoying mid-session. Toggles last until the next reload; the file stays the source of truth.
Along the bottom: reload the config, save a replay clip, start or stop recording.
One item, one scene. Bind one to Intro, one to Just Chatting, one to
Death, put them in your hotbar — and switching scenes is a right-click, without
alt-tabbing and without a Stream Deck.
The bound scene is part of the item's name, so a hotbar full of remotes reads at a glance. Sneak + right-click reopens the dashboard to re-bind.
Every action is checked on the server against your permission level. Handing someone a remote does not hand them your stream.
A condition can be a regex, and the regex hands its capture to the action. That means one rule covers every scene you own:
{
"on": "chat.message",
"when": { "op": "true", "message": "regex:^!scene (?<scene>.+)$" },
"do": [ { "type": "scene", "scene": "{scene}" } ]
}
Type !scene Just Chatting in game and OBS switches. The "op": "true" condition is
there for a reason — without it, anyone on your server could drive your stream.
/streambridge status.OBS and the Minecraft server have to be able to reach each other. For a remote server that means a tunnel; do not expose obs-websocket to the open internet.
This is version 0.1.0. The protocol layer, rule engine and rate limiting are covered by 51 automated tests, including a full handshake against a stand-in OBS server. What has not had months of use is the game side.
The chat back-channel is one-way for now. Events go from the game to OBS. Twitch and YouTube chat driving the game is planned, not shipped.
No client-side triggers. Nothing reacts to what you see, only to what the server knows. That is a deliberate boundary, not an oversight.
The dashboard and the remote have not been through a real session yet. They compile against 1.21.11 and the logic behind them is tested, but the first live run is still ahead.
