Bitfocus Companion vs OBS Hotkeys: When a Live Show Needs a Control System, Not More Shortcuts

The direct answer

OBS hotkeys are sufficient when one person needs to start a stream, change a few scenes, mute a microphone, save a replay, and stop the recording from the same computer. OBS documents those actions in its hotkey settings and its overview guide. They are direct, simple, and easy to keep working after a restart. Add Bitfocus Companion when the show needs a purpose-built control surface that can reflect state and coordinate several systems rather than merely send a keystroke.

Companion’s official project describes it as open-source control software for Stream Deck and other controllers, with a large library of connections. Its OBS module uses OBS’s built-in WebSocket server. That capability is powerful, but it adds a service, network settings, module versions, and configuration responsibility. This desk analysis is based on current official documentation, not a claim that either approach is universally more reliable.

Hotkeys have a small and useful failure surface

A hotkey lives close to the application it controls. When a solo creator assigns clear keys for scene changes, mute, record, and emergency hold, there are fewer moving parts to update. OBS documents actions such as scene switching, source visibility, push-to-talk, replay buffer operations, and recording controls. The limit is not that hotkeys are amateur; it is that they are hard to see, hard to share, and easy to collide with another application when the wrong window has focus.

Use hotkeys sparingly. Give them consistent groups, avoid combinations used by the operating system or creative software, and write the critical ones on a small card. Do not rely on thirty obscure combinations remembered only by the original setup person. Build one obvious emergency scene and one obvious audio recovery action. A small set that an operator can use under pressure is safer than a complete keyboard map nobody rehearses.

Companion earns its complexity through orchestration and feedback

The Companion OBS module documents scene, stream, recording, replay-buffer, source, and audio actions, plus feedback such as stream state, source visibility, muted audio, disk space, and frame-related variables. That feedback changes the control problem. A button can show that a microphone is muted or a stream is active instead of asking the operator to infer state from memory.

The system becomes more valuable when a single cue needs multiple actions: put OBS on a hold scene, mute a guest send, start a recorder, tell a switcher to take an input, and change a tally or light state. Those chains should be short and inspected. A button that triggers five hidden changes can create a difficult recovery if one connection is offline. Display meaningful labels, include clear ‘safe’ and ‘stop’ pages, and avoid using automation to hide decisions the operator should make deliberately.

WebSocket control deserves a security boundary

OBS’s remote-control guide documents the built-in WebSocket server and configuration options. The Companion module documentation specifies OBS 28 or later, default port information, and a password setting. Treat that endpoint as a control interface, not a convenience feature to expose openly. Use a password, bind and firewall it appropriately, and avoid forwarding the port to the public internet without a deliberate secure access design.

Put the controller and OBS machine on a trusted network segment when possible. Record the host, port, password custody, and restart order in the show notes. Test how Companion responds when OBS restarts or its scene collection changes. A surface that continues showing ‘live’ after the actual target disconnected is worse than no feedback, so make reconnection and state confirmation part of the rehearsal.

Design buttons around operator outcomes

A good control page is organized by the operation, not by every available API call. A first page might include Start, Stop, Emergency Hold, Main Camera, Guest, Playback, Microphone, and Record status. A second page can hold setup or engineering functions. Name buttons for what happens on air, use color with a text label, and keep destructive actions guarded by a long press, confirmation, or separate page where the hardware supports it.

Do not program a concealed multi-action button that starts a stream, switches program, starts music, opens a guest, and unmutes five buses unless the crew has rehearsed each dependency. Separate arming from taking an action when a wrong press would be expensive. The goal is not a spectacular Stream Deck screenshot; it is a surface that tells an operator what is safe to do next.

Plan for the moment the controller disappears

A control surface is an accessory until the show can continue without it. Keep an OBS keyboard-and-mouse route for essential scenes, audio mute, start and stop, and emergency hold. Make sure the operator can access those controls if the Stream Deck cable disconnects, Companion fails to launch, or a module no longer connects after an update.

Export or back up the Companion configuration and record module versions. Update Companion, OBS, plugins, and controller software away from show day, then test the actual buttons with the actual scene collection. Companion’s large connection ecosystem is useful, but every extra module is a dependency. Remove obsolete connections rather than carrying them through every production season.

Verdict and other resources

Stay with OBS hotkeys for a small one-person show whose core actions all happen inside OBS. Move to Bitfocus Companion when the show needs a visible, shared control surface, state feedback, or coordination across OBS and external devices. They can coexist: Companion can trigger a controlled OBS action while hotkeys remain the recovery path.

Other control options include vendor-specific Stream Deck plugins, MIDI, OSC, or dedicated switcher panels. Choose based on the systems to be controlled and the team that must maintain them. The sources below are official project and OBS documentation. Streaming Tech Reviews did not stress-test Companion, OBS WebSocket, or any controller hardware.

A practical controller rehearsal

Start with OBS closed and confirm the control computer can start the expected services. Open OBS, verify the WebSocket settings, then check the surface state against OBS itself. Trigger every critical cue once, disconnect the controller, and use the fallback hotkeys. Restart OBS and repeat the state check. That sequence finds more problems than a quick button demo.

Keep the show file, Companion backup, and emergency action card together. Control automation is valuable only when it reduces the cognitive load of the operator who is live.

Choose the least complicated surface that gives useful information

A keyboard, a compact Stream Deck, a tablet page, MIDI buttons, and a hardware switcher are all surfaces, not show strategies. Start with the decisions the operator must make per minute. A solo gameplay stream may need only scenes, mute, replay, and a break slate. A remote panel show may need guest cues, playback, lower thirds, recorder state, and an intercom reminder. The best interface keeps those critical actions visible without making a new operator hunt through folders.

Companion is especially helpful when different devices need a shared language: a button may reflect OBS state while also controlling a switcher, media player, or lighting cue through supported connections. Keep the logic documented. Name each device plainly, use static IP or reliable discovery practices where appropriate, and build a test page before the show page. Never troubleshoot a complex first-time connection on the surface that runs the live program.

There is no prize for replacing hotkeys. If OBS hotkeys are clear and the show never reaches beyond OBS, preserve that simple system. If a physical controller is added, make it an improvement in visibility and recoverability, not another opaque layer. The operator should always be able to answer: what is live, what happens if I press this, and what do I do if this button fails?

Add a rehearsal-only control page for device reconnects, audio checks, and signal verification. Keeping those engineering functions away from the on-air page reduces accidental changes and gives a second operator a calmer place to diagnose a connection.

Print or export the page map with the show notes. A controller is easiest to hand off when labels, colors, and intended outcomes remain consistent between rehearsal and the live event.

One final operating rule

Keep one person responsible for confirming on-air state after every important cue. A button press is an instruction; the program monitor is the evidence that the instruction produced the intended result.