Cloud OBS Scene Naming System for IRL Stream Teams

The simple rule

Name Cloud OBS scenes by what the producer should do with them, not by who built them or what looked cool during setup. Main Field, Backup Phone, Privacy Slate, Reconnecting, Clips, Sponsor Hold, Destination Check, and Ending are boring names. That is exactly why they work during a live IRL problem.

IRL stream teams switch under stress. The streamer is moving, the producer is watching source health, mods are reporting chat, and destinations may not all agree. A clever scene name that made sense during setup becomes a liability when someone needs to cut away from a private address or a frozen source.

StreamableRun is strongest when Cloud Hosted OBS becomes a clean operating surface. Good names make that surface faster for producers, moderators, and backup operators. Bad names turn Cloud OBS into a junk drawer full of sources nobody wants to touch while viewers are waiting.

Why naming is a production feature

Scene naming feels small until the stream goes wrong. If the main source drops, the producer should not choose between Scene 4, BRB old, Backup maybe, and Do Not Touch. They should choose Reconnecting or Backup Phone. If a privacy issue happens, they should see Privacy Slate instantly.

OBS supports scenes, sources, browser sources, and remote control. OBS's browser source docs describe a browser source as web content inside OBS, and OBS's remote control guide notes that WebSocket control can automate or control scenes and sources. Those capabilities are only as useful as the team's ability to understand the scene collection.

A scene naming system is also access control in plain language. A new producer may not know the whole show, but they can still avoid touching Archive Only, Test Source, or Local Audio Check if the names are honest. The goal is to let another trusted operator survive the first hour without a private tour of every button.

Use prefixes only when they help

Prefixes can make large scene collections easier to scan. Keep them short and consistent. LIVE, SAFE, TEST, HOLD, and END are enough for many IRL teams. Do not invent a code system that only one person remembers.

A simple collection might use LIVE - Main Field, LIVE - Backup Phone, SAFE - Privacy Slate, SAFE - Reconnecting, HOLD - Sponsor, HOLD - Clips, TEST - Audio, TEST - Destination, and END - Clean End. The prefix tells the producer the risk level before they even read the rest of the name.

Do not over-prefix sources inside the scene if the scene names are already clear. A scene called SAFE - Privacy Slate does not need five sources that all start with SAFE unless they might appear elsewhere. Use names to reduce thinking, not to decorate the list.

• LIVE: scenes intended for normal public use.
• SAFE: privacy, reconnecting, technical BRB, or low-risk fallback.
• HOLD: sponsor, waiting room, clips, or planned pause.
• TEST: audio, destination, camera calibration, or private checks.
• END: clean ending, raid handoff, or post-show slate.

Name ingests separately from scenes

An ingest is not a scene. The ingest is the source arriving from a phone, encoder, local OBS, hardware box, or guest. The scene is how the public show uses that source. Mixing those names creates confusion when the team adds backup sources.

Name ingests by device and role: Main Phone - Moblin, Backup Phone - IRL Pro, Local OBS - Desk, Guest Phone - Preview, Action Cam - Bike, Encoder - HDMI Program. Then name scenes by viewer state: Main Field, Guest Two-Up, Desk Segment, Reconnecting, Clips, Privacy Slate.

Moblin and IRL Pro can be strong mobile sources, and OBS's SRT guide shows how SRT streams can be received or sent with specific URL options. That source detail belongs in the ingest note, not necessarily in the scene name viewers never see. The producer needs both: what the source is and what the scene does.

• Ingest name answers: where is this feed coming from?
• Scene name answers: what will viewers see if I click this?
• Source note answers: protocol, expected bitrate, audio owner, and backup action.
• Runbook note answers: who can fix it when it breaks?
• Public label answers: what viewers should understand, if anything.

Make fallback names impossible to miss

Fallback scenes are not where you should be subtle. Reconnecting, Privacy Slate, Clips Fallback, Sponsor Hold, and Audio Trouble are direct. A producer should know which one to use in less than a second.

Add the important constraint to the name when needed. Privacy Slate - No Chat tells the producer this scene should not show chat. Clips Fallback - Safe Audio tells them it has approved audio. Sponsor Hold - Alerts Paused tells them browser-source alerts should not interrupt the brand segment.

StreamableRun's drop protection value is much stronger when fallback scenes are named like actions. The team can rehearse the exact call: cut to Privacy Slate. Run Clips Fallback. Go Reconnecting. Return Main Field. Those words should match the actual scene collection.

• Reconnecting: source dropped but expected back soon.
• Privacy Slate: camera must be hidden immediately.
• Clips Fallback: longer hold while source recovers.
• Sponsor Hold: brand-safe pause with alerts controlled.
• Clean End: intentional end state, not a crash.

Name browser sources by risk

Browser sources are often the messiest part of a live scene because they can contain alerts, chat, goals, TTS captions, uploads, maps, sponsor widgets, or custom controls. A vague source named Overlay does not tell the producer what risk it carries.

Use names like Chat Overlay - Public, Paid Alerts - Pausable, Upload Corner - Manual, TTS Captions - Safe, Sponsor Widget - Locked, Map - Private Test, and Goal Overlay - Public. If a source can show viewer-submitted content, say that in the name or runbook note.

OBS Browser Source is powerful because it runs web content directly inside OBS. That is exactly why source names should mention whether the source is automatic, moderated, public, private, pausable, or locked. During trouble, the producer should know which sources can safely stay visible.

• Public: safe to show in normal scenes.
• Manual: requires moderator approval before content appears.
• Pausable: producer can stop it during sponsor or privacy moments.
• Private: never belongs on public output.
• Locked: sponsor or event asset that should not be casually edited.

Keep destination names boring too

Destination names should match the platform and purpose. Twitch - Main, Kick - Secondary, YouTube - Archive, Custom RTMP - Sponsor, Test RTMP - Private. Avoid names like purple, green, backup maybe, or old YouTube. Those names force the producer to remember context that should be visible.

YouTube's encoder settings and Twitch's broadcasting guidance show why platform output decisions are not identical. Bitrate, resolution, codec support, and live control settings can differ. Destination names should help the team understand which output is being checked and why.

In StreamableRun, keeping destinations named clearly also protects stream keys. The producer can talk about Twitch - Main or Custom RTMP - Sponsor without pasting private URLs into chat. That is cleaner for security and easier for handoff.

• Platform first: Twitch, Kick, YouTube, Custom RTMP.
• Purpose second: Main, Secondary, Archive, Sponsor, Test.
• Never put stream keys in scene, source, or destination display names.
• Remove old destinations instead of leaving traps.
• Use the same destination names in the runbook and dry-run checklist.

Add owner notes outside the scene name

Do not cram every detail into the scene name. A good name is scannable. Put deeper detail in the runbook or source note: owner, protocol, expected bitrate, audio source, fallback, last test date, and who can change it.

For example, Main Phone - Moblin can have a note that says SRTLA preferred, RTMP fallback, host audio, tested July 8, producer cuts to Reconnecting after ten seconds. The scene name stays short, while the recovery information is still available.

This is especially useful for backup operators. They may not know why a source exists, but they can read the note and act. StreamableRun workflows become more mature when a second producer can run them without private memory from the person who built the first version.

• Owner: who can fix or change this source.
• Protocol: SRTLA, SRT, RTMP, local OBS, hardware encoder, or browser.
• Audio: public, muted, backup only, or follows scene.
• Fallback: what to show if it fails.
• Last tested: date and route or event context.

Audit names before every big stream

Scene collections rot. A stream adds one sponsor scene, two test sources, three old overlays, and a guest camera. Two weeks later nobody knows which ones are safe. Run a naming audit before important IRL streams.

Delete or archive scenes that are not part of the current show. Rename sources that only the original builder understands. Confirm safe scenes have safe audio. Confirm private scenes cannot be sent public by mistake. Confirm destination names match the actual platforms.

The audit should be fast. If it takes an hour to understand the scene collection, that is proof the naming system failed. Fix the names before adding more automation.

• Remove unused test scenes from the live collection.
• Rename any source with old, copy, final, maybe, or temp.
• Confirm every SAFE scene is actually safe.
• Confirm every browser source says public, manual, private, pausable, or locked where relevant.
• Have a backup producer find Main, Privacy, Reconnecting, Clips, and End without help.

Other resources

These guides help connect naming discipline to producer handoff, multiple ingests, and remote OBS control.