Owncast and YouTube are separate RTMP destinations, each with its own server address and stream key. To send the same programme to both, configure two supported outputs or use a relay; putting the Owncast key into YouTube’s Live Control Room, or the YouTube key into Owncast, will not connect the services.
The simplest way to begin is to test each connection on its own. First send an encoder to Owncast using Owncast’s endpoint and key, then set up YouTube with the URL and key shown for a YouTube stream in Live Control Room. Once both work independently, decide how you want to operate both at once.
Understand the two-destination workflow
Think of this setup as three parts: the programme source, the encoder, and the destination receiving the encoded feed. Owncast is one destination; YouTube is another. The encoder sends video and audio to whichever destination its output settings specify.
When you configure an encoder for Owncast, the server field points to your Owncast installation and its key identifies the incoming broadcast there. Those credentials belong to Owncast. When you configure an output for YouTube, you copy a different server URL and key from that YouTube stream’s Live Control Room settings. Those credentials belong to YouTube.
A single ordinary output configured for Owncast does not also send a copy to YouTube. The address and key identify a particular receiving endpoint, not a general-purpose channel connection. To send the same programme to both, your chosen workflow must create two outputs or forward the incoming stream through a relay. Confirm the current capabilities and protocol support of the software or service you plan to use rather than assuming it can do this.
It helps to draw the two paths before configuring anything:
| Destination | Server or URL comes from | Key comes from | What the encoder sends |
|---|---|---|---|
| Owncast | Your Owncast host and its RTMP ingest path | Owncast admin settings | One incoming feed to Owncast |
| YouTube | The selected stream in YouTube Live Control Room | That same YouTube stream’s settings | One incoming feed to YouTube |
Keep both rows distinct in your notes. For a longer-running channel, decide whether both destinations need to be live continuously, whether one is a backup, and where the programme will be monitored. If your underlying goal is a continuous YouTube broadcast from a playlist, the planning considerations in making a 24/7 Punjabi Bhangra stream from an M3U playlist may help you think through the programme source separately from the connection settings.
Find Owncast’s RTMP endpoint and stream key
Owncast’s documented RTMP ingest uses TCP port 1935 by default and the /live path. A common base address for an encoder is rtmp://<owncast-host>:1935/live. Replace <owncast-host> with the host name or address used to reach your Owncast installation. The key is normally entered in the encoder’s separate stream-key field.
Owncast also documents a full URL form that appends the key to the path: rtmp://yourserver:1935/live/<your-stream-key>. Encoder interfaces do not all present their fields the same way. If the interface has separate server and key fields, use the base /live address in the server field and the matching Owncast key in the key field; do not append the key as well unless that encoder’s instructions specifically require a single complete URL.
In Owncast’s admin interface, go to Configuration > Server Setup > Stream Keys to view or manage the stream keys. Owncast can issue multiple keys, which can be useful if you want to distinguish a production encoder from a test device. Label or record them securely so you know which one to revoke if a device or operator no longer needs access.
If Owncast is newly installed, check its initial setup guidance before broadcasting. Owncast documents abc123 as an initial default stream key in its getting-started material and tells operators to change it. Treat that value as a setup warning, not a credential to use for a live channel. The Owncast admin password is another credential and should also be changed; it is not the stream key. See Owncast’s first-stream guidance and its broadcasting documentation for the current instructions.
The endpoint must also be reachable from the encoder. If Owncast is behind a firewall or cloud security group, its RTMP port must be allowed for incoming traffic. Owncast’s installation documentation identifies port 1935 for RTMP ingest and 8080 for its web interface; these serve different purposes, so access to the admin page alone does not show that RTMP ingest is reachable. Check your host’s current firewall rules and installation notes before opening a port.
Configure the encoder for Owncast
In OBS, use a custom streaming service rather than selecting YouTube as the destination. Open the stream settings and set the service to a custom server, then enter the Owncast base RTMP address in the server field and the Owncast key in the stream key field. Owncast’s OBS guide describes these custom server and key fields.
Before you start, check the host name, port, path and key separately. A missing /live path, a typo in the host name, or using the key from another destination can all prevent the connection. If your encoder accepts only a single URL, consult that encoder’s current guidance and use the documented full Owncast URL form accordingly. Avoid pasting a full URL and then entering the same key in a separate field unless the software explicitly expects that combination.
Begin with output settings that your Owncast host and network can handle. Higher resolution or bitrate can require more processing and upload capacity, and a setup that works for a short test may not be suitable for a continuous channel. Owncast says RTMP-compatible broadcasting software is generally compatible, but it has not tested every possible encoder. If you use FFmpeg on a VPS, for example, review how CPU use affects an FFmpeg YouTube stream as one part of sizing and monitoring your setup; the right settings still depend on your source, host and output.
Start the encoder and check Owncast’s viewing page or admin status for the incoming broadcast. If it does not appear, verify that the stream key came from Owncast, that the /live endpoint is correct, and that inbound TCP port 1935 is reachable. Then inspect the encoder log for a connection or authentication error. Change one setting at a time so you can tell which correction resolved the failure.
Get YouTube’s URL and key in Live Control Room
For YouTube, sign in to YouTube Studio and choose Create > Go Live. Create or select the stream in Live Control Room, then copy the server URL and stream key shown for that stream. YouTube’s encoder setup instructions explain how to connect an encoder. The URL and key shown there are for YouTube, not for Owncast.
Keep the URL and key together as a pair. If you select a different YouTube stream or scheduled event, check that the credentials you have copied belong to that selection. YouTube’s stream key is not a substitute for the Owncast key, even if both settings screens use the words “server” and “key”. Likewise, do not copy Owncast’s /live address into YouTube’s encoder settings.
YouTube offers RTMP and RTMPS connection details. RTMPS is RTMP carried over TLS/SSL, and YouTube recommends using it when your encoder supports it. Obtain the RTMPS address from Live Control Room rather than adapting the Owncast address by hand. Owncast’s documented ingest instructions describe RTMP at its own endpoint; do not assume that YouTube’s RTMPS URL can be used for Owncast. See YouTube’s guidance on streaming with RTMPS and confirm the protocol settings separately for each destination.
For a scheduled YouTube stream, starting the encoder may first send a preview to Live Control Room rather than immediately making the event public. You may need to inspect the preview and then press Go live in YouTube. This is a separate step from starting the encoder, so include it in your operating checklist when a human needs to publish the event.
Configure a separate YouTube output if needed
If you want the same programme to appear on Owncast and YouTube at the same time, the encoder or relay must support two simultaneous destinations. Configure one output with Owncast’s server and key, and a second with the YouTube URL and key. Do not overwrite the first destination’s details when creating the second output, and do not assume that selecting a second platform in an interface preserves both outputs without checking.
Some encoders may offer multi-output features, while others may need an additional supported workflow. Capabilities can depend on the software, version and platform, so check the current documentation for the exact tool you will use. If the workflow relays a feed rather than sending two direct outputs, confirm that the relay supports both required ingest protocols and that the receiving services accept the format it sends.
A relay can reduce the need for your local connection to upload two full feeds, but it adds another service and another point to monitor. Direct dual output avoids that relay but needs enough upload capacity from the broadcaster’s connection for both streams. In either case, keep an eye on processing load, network stability and the stream quality accepted by each destination. If the channel is a simple YouTube-only 24/7 loop rather than a programme that needs Owncast as well, the connection design may be different; creating a 24/7 Shabad Kirtan stream offers a relevant example of planning the channel itself.
Owncast documents a custom-RTMP route through Restream, and its guide states that a paid Restream account is required for that route and that Owncast’s port 1935 must be publicly reachable. That is a documented route, not a requirement for every dual-output setup. Check the current vendor documentation and terms before choosing any paid relay. Choose based on the workflow you need, protocol compatibility, upload capacity and whether you are comfortable adding another service.
Before relying on a dual-output arrangement overnight, test both outputs together for long enough to observe how the actual encoder, connection and destinations behave. Verify both receiving previews, and confirm which destination requires a separate action before a scheduled YouTube event goes public. For channels where an interruption matters, decide who will notice a failed output and what they should do next; the practical checks in how to secure a live video stream can help with access and operational planning.
Start and verify each connection
Test the destinations independently first. For Owncast, start its configured output and confirm that Owncast receives and displays the broadcast. For YouTube, start the YouTube output and confirm that Live Control Room shows the incoming preview. This separates destination and credential problems from issues caused by a multi-output setup.
Once each works on its own, enable both outputs if your chosen workflow supports that. Check that the preview or status on each side is present, that audio and video are as expected, and that neither output has been inadvertently stopped while the other started. A working Owncast player does not prove that YouTube is receiving a feed, and a YouTube preview does not prove that Owncast is connected.
For a scheduled YouTube event, wait for the preview and use Live Control Room to press Go live when appropriate. If the broadcast is meant to remain on continuously, write down who is responsible for that manual step and how they will check that the event has actually begun. Do not assume that encoder status alone means the YouTube event is public.
If a connection fails, trace the relevant path rather than changing both configurations at once. For Owncast, check its host, port 1935, /live path, key and firewall reachability. For YouTube, check the selected event, its current URL and key, the encoder’s output status and any RTMPS setting. If only one of two outputs fails, leave the working destination’s settings alone while you troubleshoot the other.
Protect and rotate stream keys
Treat each stream key like a password that grants permission to send video to a destination. Do not publish it in a public chat, screenshot, help request, shared document or recording. Limit access to people and devices that need to operate the channel, and use a password manager or another access-controlled method to keep a record of which key belongs to which destination.
Keep Owncast and YouTube credentials in clearly labelled, separate records. If an encoder has a saved configuration, check who can access that computer or account. When an operator leaves or a device is retired, remove access where possible and replace the affected key rather than continuing to share it. For Owncast, use the admin controls to manage keys; for YouTube, manage the key from the relevant stream settings in Live Control Room.
If you suspect a key has been exposed, rotate it at the destination that issued it, then update only the corresponding encoder output. A changed Owncast key does not change YouTube’s key, and changing YouTube’s key does not revoke Owncast access. Test the revised connection and confirm the receiving destination is working before relying on it for a live programme.
Also keep the admin password distinct from either stream key. A stream key is for the encoder-to-ingest connection, while an admin password controls access to Owncast’s settings. Do not reuse the initial Owncast defaults or use one credential for both jobs. A short written procedure for storing, changing and verifying keys is more useful during an outage than relying on someone to remember which value goes where.
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 use the Owncast stream key in YouTube?
No. Owncast’s key authenticates a feed to Owncast, while YouTube’s key is issued for the selected YouTube stream in Live Control Room. Each destination needs its own server URL and matching key.
What is Owncast’s default RTMP address?
Owncast documents RTMP ingest on TCP port 1935 by default, using the /live path. In a typical encoder with separate fields, use rtmp://<owncast-host>:1935/live as the server and the Owncast-issued key as the key; check the current Owncast guide for any installation-specific differences.
Why does YouTube show a preview but not a public live stream?
For a scheduled stream, the encoder can send a preview to Live Control Room before the event is published. Check the preview, then press Go live in YouTube when the event is ready to begin.
Do I need a relay to send both destinations the same programme?
Not necessarily. An encoder that supports separate simultaneous outputs may be able to send one feed to each destination directly; a relay is another possible workflow. Check current tool capabilities, protocol support, network capacity and any paid-service requirements before choosing.