Owncast and YouTube use separate stream keys. For a documented OBS-to-Owncast setup, put the Owncast key in OBS with Owncast’s server address; to send an encoder stream to YouTube, put the YouTube key in the encoder’s YouTube destination settings.
Do not put a YouTube key into Owncast’s Stream Keys area. The official configurations reviewed here describe Owncast as an incoming destination for broadcaster software; they do not document Owncast forwarding an incoming stream to YouTube. If you need both destinations at once, first verify that your chosen encoder or relay explicitly supports that arrangement and explains how it stores each credential.
Understand the two separate stream keys
A stream key is a credential that lets an encoder send a broadcast to a particular destination. It is not a universal password that works across streaming platforms. Owncast’s key authorises broadcaster software to send a stream into your Owncast instance; YouTube’s key belongs to the YouTube live stream configured in YouTube Studio.
The two keys therefore answer different questions. The Owncast key says, in effect, “this encoder may send video to this Owncast server”. The YouTube key is used by an encoder to publish to YouTube. Owncast’s documentation places its keys in server setup and describes the /live ingest endpoint. YouTube describes its key as password-like and has creators enter it in encoder settings for YouTube. See Owncast’s first-stream setup guide and YouTube’s live stream settings help.
That distinction matters if you are following a tutorial that says “add your YouTube stream key to Owncast”. The label “stream key” may appear in both products, but the fields are not interchangeable. Adding a YouTube credential to Owncast’s own key list would not make it an Owncast ingest key, and the reviewed documentation does not establish that this creates an outbound YouTube connection.
If you are only trying to broadcast to Owncast, you need an Owncast key and the Owncast server URL. If your aim is to publish on YouTube, configure YouTube directly as a destination in your encoder. If you are trying to publish to both, treat that as a separate multi-destination design question rather than assuming that the two documented single-destination configurations combine automatically.
Find the Owncast key in server setup
Before configuring an encoder, make sure your Owncast server is running and reachable from the computer that will broadcast. Sign in to the Owncast admin interface, then open Configuration > Server Setup > Stream Keys. The names and placement of controls can change between versions, so use the current Owncast documentation or your instance’s interface if the menu differs.
Create or choose a key intended for broadcaster software. Owncast’s stream key is separate from the admin password. Do not use your admin password as an encoder key, and do not assume that knowing one credential grants the same access as the other. Owncast allows separate stream keys to be managed and revoked, which can be useful if more than one encoder or operator needs access. Its key and first-stream documentation explains the key’s role and the incoming /live endpoint.
Copy the Owncast key only when you are ready to place it in the encoder’s credential field. Avoid leaving it visible while screen-sharing, recording a tutorial, or capturing a support screenshot. If you administer a shared channel, agree who is allowed to see or replace the key; a person with access to the encoder configuration may also be able to use the credential to send a stream.
The server address is a separate value from the key. You will need the address and ingest port configured for your Owncast instance. A common documented pattern is an RTMP address ending in /live, but the actual address and port depend on how that instance is configured. Copy the value for your server rather than guessing from an example in a guide. A wrong address cannot be fixed by changing the key, and a correct address does not make a YouTube key appropriate for Owncast.
Configure OBS for Owncast ingest
In OBS, open Settings > Stream and select Custom as the service. Enter the Owncast RTMP address in the server field and the Owncast stream key in the stream key field. Owncast’s OBS guide documents this Custom-service arrangement. Check the actual port and URL for your Owncast installation; examples in documentation are not a substitute for your configured server address.
Before going live, review the fields once, without sharing the screen. A common mix-up is to paste the YouTube key into the OBS Custom key box simply because the stream is ultimately intended for YouTube. In this setup, OBS is sending to Owncast, so that box must contain the Owncast key. The stream destination follows the server URL and service configuration, not the name you gave the video or the platform you intend to reach later.
Start the stream and check Owncast’s status page or viewer page to confirm that the incoming broadcast appears. This is a configuration sequence from the product documentation, not a promise that every server, network, or OBS installation will behave identically. If Owncast does not show an incoming stream, first check that the server is accessible, then verify the URL and port, and finally check that the matching Owncast key is current. Change one item at a time so you can identify the cause.
If you are using a home connection, an unstable upload path can interrupt ingest even when the credentials are correct. For example, a prayer channel broadcasting over mobile broadband may need to check both the encoder’s connection and the network’s ability to sustain an outgoing stream. Our guide to running a 24/7 prayer stream on a Jio connection covers the practical network side. It does not alter which service’s key belongs in OBS.
Configure YouTube in the encoder separately
To publish an encoder stream to YouTube, open YouTube Studio’s Live Control Room and obtain the stream URL and key for the scheduled or current stream. In your encoder’s YouTube destination settings, select YouTube’s preset if available, or enter the YouTube URL and YouTube key in the fields the encoder provides. YouTube’s encoder setup instructions describe entering those values in encoder settings.
These are YouTube destination values. Do not put them in Owncast’s Stream Keys screen. If you have been configuring OBS for Owncast, changing OBS to a YouTube destination is a different configuration: the destination URL and key must match YouTube, not the Owncast instance. Confirm which service the encoder is currently sending to before you start a broadcast.
Where your encoder and YouTube’s Live Control Room offer RTMPS, use the RTMPS URL for the YouTube connection. YouTube describes RTMPS as RTMP carried over TLS/SSL; this protects the connection in transit between encoder and destination. Read YouTube’s RTMPS guidance and follow the URL shown for the live stream rather than adding or changing a protocol by guesswork.
RTMPS is not a cure for a key displayed in a screenshot, exposed in a shared document, or accessible to someone who can open the encoder settings. It protects transport, not the places where you copy, store, or display a credential. Keep the key out of public chat and screen recordings whether or not the connection uses RTMPS.
The reviewed Owncast and YouTube documentation does not verify a workflow in which Owncast receives one stream and forwards it to YouTube. Nor does it verify that one encoder can safely send to both platforms simultaneously. If simultaneous publishing is a requirement, check the current documentation for the specific encoder or relay you intend to use. Confirm that it supports multiple destinations, that you know where each key is held and who can view it, and that revoking one destination’s key will not create an unexpected interruption elsewhere.
Keep keys out of screenshots and shared logs
Treat the YouTube stream key as a password. YouTube itself describes stream keys as password-like, so do not include a live key in a public issue, support chat, tutorial image, or screen recording. Apply the same care to an Owncast key: anyone who can use it may be able to send video to that Owncast ingest endpoint.
When configuring OBS, avoid showing the credential field during a public screen-share. If you need to ask someone for help, crop or blur the key and any other credential before sharing a screenshot. Check the original image after editing; blurring a small area can leave enough characters visible to recover a key, and an unedited source image may remain in a shared folder or messaging history.
Avoid placing keys in a public URL, shell history, source-controlled configuration, or logs. These are general secret-handling precautions, not claims about a particular Owncast or OBS feature. Use the encoder’s credential field, restrict access to the computer or account where the encoder is configured, and remove old copies of keys from notes or shared files when they are no longer needed.
For a small team, a simple handover rule prevents many accidental disclosures: only the person configuring the destination copies its key, and others receive instructions without the secret itself. If a volunteer needs to operate a channel, show them how to start and stop the broadcast without sending credentials in a group chat. If the key must be shared with an administrator, use a private method and make sure the recipient understands which platform it belongs to.
If you are troubleshooting a stream that stopped overnight, preserve useful error messages but scan for secrets before posting logs. A log can be useful without containing a key. Our 3AM failure checklist is a practical starting point for separating connection, encoder, and destination problems without publishing credentials.
Rotate a key if it is exposed
If you think a YouTube key has been exposed, reset it in YouTube Studio’s Live Control Room under the Stream tab, then replace the old value in the encoder’s YouTube destination settings. YouTube says a channel owner or manager must reset a compromised key. Check the current YouTube live stream settings page for the available controls and access requirements.
The reset may interrupt an encoder still using the previous key. Plan to update the encoder promptly, and verify the live stream using the new key before relying on it for a scheduled broadcast. If several people or machines have copies, update each authorised configuration and remove obsolete copies where practical. Do not send the replacement key to the same public place where the old one was exposed.
If the exposed credential is an Owncast key, revoke or replace it in Owncast’s Stream Keys settings instead. That action is separate from a YouTube reset. If both keys may have been shown, rotate both in their respective services, then update the relevant encoder destination fields. A key change in one platform does not invalidate the other platform’s credential.
After rotating, check the broadcast path carefully. Confirm that OBS still points to the intended destination and that the field contains the current key for that destination. If you are keeping a 24/7 stream running, choose a suitable maintenance window where possible and have a way to check status after the change. Do not assume a service will continue broadcasting through a credential reset or that a reset itself repairs unrelated network or encoder faults.
Choose the publishing path before sharing credentials
For a single destination, the clearest arrangement is one encoder configuration for that destination: Owncast URL plus Owncast key for Owncast, or YouTube URL plus YouTube key for YouTube. Keep a note of the destination name beside your operational instructions, but not the key itself. That small distinction is especially helpful if you alternate between a private Owncast preview and a public YouTube broadcast.
For two destinations at once, there are design choices that the reviewed official pages do not settle. A multi-destination encoder or a relay may have its own documented support and secret-handling model, but do not infer that capability from the existence of two stream-key fields in different products. Before entering credentials, check whether the chosen software can publish to both destinations, whether each connection supports encrypted transport, who can read stored keys, and what happens if one destination disconnects or a key is revoked.
There is also a practical network trade-off. Sending directly to multiple destinations can require more upload capacity from the broadcaster, while a relay-based design shifts some of the work elsewhere and introduces another system to configure and monitor. The appropriate arrangement depends on your encoder, connection, and operational needs. If your current goal is simply to keep a YouTube loop live from a local computer, this guide to running a YouTube channel from a home server with FFmpeg discusses a different publishing arrangement; it should not be read as evidence that Owncast itself forwards to YouTube.
For an always-on channel, make a brief recovery note that says which destination is configured, where its official reset process is, and who can carry it out. Do not write the key into the note. Test changes while someone can observe the encoder and destination, then record the result without capturing secret fields. This gives the next operator enough context to recover the stream without turning the handover document into another place where credentials can leak.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I put my YouTube stream key in Owncast’s Stream Keys settings?
No. Owncast’s Stream Keys settings are for credentials that broadcaster software uses to send video into Owncast. YouTube’s key belongs in the encoder’s YouTube destination settings; the reviewed documentation does not show Owncast forwarding its incoming stream to YouTube.
Which key goes in OBS when I select Custom for Owncast?
Use the Owncast key, along with the RTMP server address for your Owncast instance. If OBS is instead configured to publish to YouTube, use the YouTube URL and key from YouTube Studio in the YouTube destination configuration.
Does RTMPS keep my stream key secret?
RTMPS encrypts the stream connection in transit when supported and configured with YouTube’s RTMPS URL. It does not hide a key shown in a screenshot, exposed in a log, or accessible to someone who can open the encoder settings.
What should I do if someone saw my key?
Reset the exposed key in the service it belongs to, then update the matching encoder configuration. Reset the YouTube key in YouTube Studio; revoke or replace an Owncast key in Owncast’s Stream Keys settings. If both credentials were exposed, handle each separately.