Stream-Key Rotation Runbook for Cloud OBS and Multi-Destination Shows

The direct answer

Rotate a stream key by identifying the exact capability it controls, replacing it in the right layer, testing privately, and revoking the old value only after the new path is proven. Do not treat every secret as the same thing. A contribution ingest key, a Twitch or YouTube destination key, an OBS WebSocket password, and a platform-account login create different risks and need different recovery paths.

YouTube’s encoder troubleshooting guidance tells operators to create or copy a new stream key in Live Control Room when a third-party encoder has trouble. Twitch’s Stream Manager is the platform’s operating surface for managing a broadcast. Those official tools matter, but a multi-destination show still needs its own map of where each credential is used before a producer changes anything mid-event.

For StreamableRun, keep the field contribution into the server separate from the Cloud Hosted OBS destination outputs. That separation means a destination-key rotation can often happen without asking a field streamer to rebuild their mobile encoder, and a contribution-key issue does not automatically require touching every public destination.

Classify the credential before rotating it

Start with four labels. Contribution credentials get a camera, phone, local OBS, or hardware encoder into StreamableRun. Destination credentials publish the Cloud OBS program to Twitch, YouTube, Kick, or a custom RTMP target. Control credentials let an operator change OBS. Account credentials manage the platform itself. Put the affected value in one label before taking action.

This avoids the expensive mistake of changing a destination stream key when the actual issue is an expired field-encoder configuration, or resetting OBS control access when the platform refuses an output. A secret incident is stressful enough without breaking working parts of the show by trial and error.

Record owners, not raw values, in the runbook. The line should say ‘YouTube destination key: destination producer, secure vault reference, last verified date,’ not include the key in a shared note. If an operator needs the value, retrieve it through the approved secret system and keep it out of chats, screenshots, ticket comments, and browser-source URLs.

• Contribution key: source to StreamableRun.
• Destination key: Cloud OBS program to a named platform.
• Control credential: changes OBS, not video delivery.
• Account credential: platform ownership and settings.

Decide whether this is scheduled or emergency rotation

A scheduled rotation is a maintenance task. Choose a quiet window, make replacement values, update a duplicate configuration, test on a private destination, promote during a planned cut, then revoke the old value. There is no prize for doing a low-risk scheduled rotation while a major event is live.

An emergency rotation is different: a key may have appeared in a recording, a screenshot, an untrusted integration, a public paste, or an access review. Preserve evidence without copying the secret around, notify the assigned owner through the approved internal path, and decide whether the affected destination or contribution must be cut immediately. The severity depends on what the key can do and whether it is actually exposed.

Do not announce secret details on a public stream or in a public chat. The viewer-facing message, if one is needed, can simply say the team is resolving a technical issue. The runbook should focus on containment, a stable program, and verified recovery rather than explaining credentials to an audience.

• Scheduled: test first, promote calmly, revoke old access after verification.
• Emergency: contain exposure, identify scope, and use the affected layer’s fallback.
• Keep key material out of incident notes and communications.
• Separate the audience message from the technical response.

Rotate a destination key without losing the program

When a Twitch, YouTube, or other destination key is the affected credential, first confirm that the contribution and Cloud OBS program are healthy. Take a note of the current destination state, then create or retrieve the replacement through the platform’s approved dashboard. YouTube’s troubleshooting guide specifically points operators to Live Control Room to copy a new stream key when updating a third-party encoder.

Update only the named destination configuration in a staged profile or approved destination record. Do not paste the new key into browser-source notes or a shared text document. If the platform allows a private test, send a short moving image and real program audio to it. Confirm platform acceptance, intended privacy state, title/category if relevant, and viewer-side playback.

During a live show, a producer can keep other destinations running while the destination owner handles this one route. If the affected platform cannot be restored quickly, preserve the Cloud OBS program and use the show’s communication plan. Do not restart every target just to make the destination list look symmetrical.

• Confirm source and Cloud OBS program before changing a destination.
• Create replacement values in the platform’s official operator surface.
• Update the one staged destination route and test with moving picture plus audio.
• Keep unaffected destinations stable while recovery happens.

Rotate a contribution key without confusing destinations

A contribution-key rotation changes the path from the field source into StreamableRun. It does not necessarily change Cloud OBS scenes or public destinations. Prepare the replacement in the source app or encoder using the vendor’s documented workflow, then rehearse it on a backup source or a private path when possible.

Before you cut over, make sure the producer can identify primary and backup sources in Cloud Hosted OBS. Put a stable BRB or backup scene within one action. The field operator receives a short instruction: which source is moving, when to reconnect, and what confirmation to wait for. They should not be asked to change unrelated destination settings.

After the new contribution appears, check video, audio, sync, and source stability in Cloud OBS before declaring success. Then verify at least one public destination. A source can reach the server while an audio route or scene binding is still wrong. If it fails, use the approved backup contribution or safety scene while the key issue is isolated.

• Treat source-to-server key rotation as a contribution-layer operation.
• Prepare visible primary, backup, and safety scenes first.
• Give the field operator one precise reconnection instruction.
• Verify source quality in Cloud OBS and public output after cutover.

Rotate OBS control credentials separately

OBS WebSocket credentials do not publish video, but they can change the program. The OBS WebSocket project recommends password protection and explains that the endpoint is used for remote control. Rotate this credential when a control integration or producer loses authorization, and update only the approved controllers that need it.

Test control access in a private session before removing the old credential from a critical controller. Verify that the controller can authenticate, read current state, complete an allowed action, and stop safely if it receives an error. Keep manual Cloud OBS access available during the change; automation should never be the only way to reach Main or Backup.

Do not reuse a destination stream key as an OBS password or use one generic secret for every integration. The point of separation is containment. If a browser controller is retired, you should be able to revoke its access without touching the field phone or every platform output.

• Rotate remote-control access independently from delivery secrets.
• Test authentication and a narrow approved action in private.
• Keep manual Cloud OBS control available.
• Do not reuse secrets across contribution, destination, and control layers.

Make post-rotation verification explicit

Verification needs three views. First, configuration: the new credential is stored only in the approved destination, encoder, or controller. Second, technical delivery: the expected source or destination connects and carries moving video with program audio. Third, viewer-facing behavior: the correct platform account, privacy setting, title/state, and playback are visible where intended.

Then revoke or invalidate the old credential through the platform or system that issued it, unless an emergency runbook requires keeping it briefly for a controlled fallback. Record the time, owner, scope, old-value status, new-path result, and anything left to recheck. Do not record the values themselves.

Finish with an access review. Remove unused controllers, old device profiles, and temporary producer access. Rotation is not complete when the new key works; it is complete when the old capability is no longer an easy path into the production.

• Verify configuration, technical delivery, and viewer-facing state.
• Revoke old access only after the replacement path is proven, unless containment requires immediate invalidation.
• Log scope and result without logging secrets.
• Remove temporary controllers and stale access after the event.

Other resources

Use each platform’s official operator documentation to create and manage replacement stream keys. YouTube’s troubleshooting page covers updating an encoder with a new key; Twitch Stream Manager is Twitch’s operator surface. OBS WebSocket documentation is relevant only to remote control credentials, which should remain separate from delivery keys.