You find your YouTube stream URL and key in the Live Control Room in YouTube Studio, under the Stream tab. To send a stream through Nginx RTMP, configure the encoder-to-relay connection separately from the relay-to-YouTube connection, and verify that your actual module build supports the destination protocol before relying on RTMPS.
The key is a credential, not a complete configuration: it does not choose the right endpoint, make an unsupported protocol work, or confirm that YouTube is receiving a usable feed. Copy the details from the stream you intend to use, keep the key private, and wait for the Studio preview before making a scheduled broadcast public.
Open YouTube Live Control Room
Sign in to the channel that will broadcast and open YouTube Studio. Select Create, then Go Live to enter Live Control Room. The exact labels or arrangement can change, but YouTube’s live streaming getting-started instructions describe this route and the setup process.
Before configuring an encoder, confirm that the channel is eligible to go live. YouTube says the channel must be verified and have no live-streaming restrictions during the preceding 90 days; its current guidance also sets a minimum age of 16. First-time live activation can take up to 24 hours, so do not leave activation until the day of a planned broadcast. Check YouTube’s current requirements directly if the channel is new or access has changed.
Live Control Room is where you choose or create the stream, retrieve its connection details, and inspect the incoming preview. Nginx is not a substitute for this Studio step. The relay forwards a feed, while Studio remains the place to select the intended broadcast and confirm what YouTube receives.
If your goal is a continuous channel rather than a one-off event, plan the programme and source files before touching the key. For example, a devotional channel that rotates recorded bhajans needs to settle its playlist, audio transitions and intended stream before its relay configuration is tested. The 24/7 devotional live stream setup guide covers that broader planning; the stream key procedure here is the same whichever subject your channel carries.
Create or select a stream
In Live Control Room, select the Stream tab. If this is the first time you are setting up a stream, create one and follow the prompts. If you have streamed before, Studio may load settings from an earlier stream. Check that you are working with the right stream before copying anything, especially if the channel has separate streams for regular programming and scheduled events.
You may be able to create a custom stream key for reuse. Reuse is convenient when the same encoder or relay repeatedly serves the same channel, but it also means more configurations can depend on one credential. A key tied to a particular workflow can make it easier to identify which connection needs updating if you reset it. Choose based on how you operate; avoid keeping unused keys simply because they were once convenient.
Do not assume that a previously saved stream selection is correct just because its preview or other settings appear familiar. A relay configured for one stream key may keep trying to publish there even after you intend to use another Studio stream. Match the Studio stream and key to the broadcast you are setting up, then record a label for the stream in your private operational notes without recording the credential itself.
For a scheduled broadcast, leave time to test before the public start. A schedule and a working feed are different things: the event can exist in Studio while the encoder or relay is not yet delivering a compatible stream. If you operate from a VPS, the continuous YouTube restream guide provides useful context on the broader relay arrangement, but the module and protocol checks in this article still apply to your installation.
Copy the Stream URL and stream key
In the selected stream’s settings, copy the Stream URL and the matching stream key. YouTube’s stream settings help page explains where these details appear. Studio may provide more than one URL or an option to reveal an RTMPS URL. Use the endpoint shown for the stream and protocol you are configuring, rather than assuming that a remembered address is still appropriate.
Treat these as two different values. The URL identifies the ingest destination; the key identifies the stream credential used to send a feed to your channel. In a typical encoder interface, the URL goes in a server or address field and the key goes in a separate stream-key field. Some interfaces combine them into a single destination field. Follow the field instructions for the software or module you are using, and do not add the key to the URL unless that interface explicitly expects it.
Copy carefully. A missing character, accidental space, stale key, or mismatched URL can stop the connection, but a correctly copied key alone does not prove that the video and audio formats are acceptable or that the relay can reach YouTube. If the connection fails, check each layer separately rather than repeatedly rotating the key without evidence that it is the problem.
Do not paste a live key into public documentation, a screenshot, a source repository, or an unsecured support message. For a tutorial, use a visibly fictional placeholder and make clear that it is not usable. Keep private notes limited to non-secret labels and the location of the protected configuration. If the key may have been exposed, reset it in Live Control Room and update every encoder or relay that uses it; YouTube explains the key’s role and management in its live stream settings guidance.
Put the key at the right point in the relay chain
A relay setup has two separate publishing legs. First, your encoder sends a stream to an Nginx RTMP application. Second, Nginx pushes that incoming stream to YouTube’s ingest destination. The first leg is encoder-to-relay; the second is relay-to-YouTube. They may use different addresses, credentials and protocols, so do not copy the YouTube destination into the encoder’s local relay field by mistake.
At a conceptual level, the encoder is configured with the address of your Nginx application and whatever local publishing name or credential that application expects. Nginx is then configured to accept that publisher and forward the stream to YouTube using the selected YouTube URL and stream key. The key belongs to the component that opens the YouTube publishing connection. In a relay design, that is ordinarily the outbound relay configuration, not necessarily the encoder’s connection to Nginx.
The exact Nginx directives and field syntax depend on the deployed module and its version. The nginx-rtmp-module project documentation describes RTMP applications and relay behaviour, but a conceptual description is not a tested configuration for every build. Consult documentation matching the module actually loaded on your system. A configuration example copied from another machine may use directives, module packaging or protocol behaviour that your installation does not have.
Keep the two legs visible in your troubleshooting notes. For example, write down whether the encoder can publish to the relay, whether the relay reports an outbound connection attempt, and whether Studio shows an incoming preview. These observations distinguish a local encoder issue from a relay issue or a YouTube ingest issue. Avoid placing the secret itself in diagnostic notes or logs.
This separation also clarifies whether a relay is necessary. If your encoder can publish directly to YouTube using a supported secure protocol, an extra relay adds another component to configure and observe. A relay can be useful where the source and destination need to be separated or where the relay is part of a continuous-stream setup, but it does not automatically improve reliability. If you are managing a 24/7 channel, also consider how you recover the source after a disconnect; the guide to handling FFmpeg drops during Indian broadband outages discusses a different failure layer from stream-key setup.
Check whether your Nginx build supports RTMPS output
YouTube recommends RTMPS for encrypted ingest. RTMPS is RTMP carried over TLS, so it is not enough for a module to accept ordinary RTMP publishers or to support an RTMP push relay. You must verify that the specific Nginx RTMP module build and operating environment can make an encrypted outbound connection to the RTMPS endpoint shown by Studio.
The name “Nginx RTMP” does not settle this question. The third-party nginx-rtmp-module project documents RTMP streaming and relay functionality, while NGINX Plus has separately maintained RTMP module documentation. Those are different variants, and installation, module loading and supported behaviour can differ. The NGINX Plus RTMP module guide is relevant if that is the variant you run; do not treat it as proof about a third-party module or another build.
Check the module’s documentation for the installed version and confirm the outbound protocol it supports. If the documentation is unclear, verify with the maintainer or test in a non-critical setup before scheduling an event. YouTube’s RTMPS encryption guidance explains the secure ingest option and how to obtain its endpoint in Live Control Room. Use that endpoint only when your actual relay path supports it.
| Connection leg | What to configure | What to verify |
|---|---|---|
| Encoder to Nginx | The relay’s address and the local application or publishing details | The encoder can reach the relay and Nginx accepts its publisher |
| Nginx to YouTube | The Studio destination URL and the YouTube stream key | The module build supports the chosen outbound protocol and Studio receives the feed |
| Direct encoder to YouTube | The Studio destination URL and key in the encoder | The encoder supports the selected protocol and the channel preview appears |
If your build cannot establish RTMPS output, do not quietly replace the secure destination with a plain RTMP push just to get past the connection error. Choose an encoder or relay path that can connect to the recommended encrypted endpoint, or get advice specific to the installed module. The trade-off is practical: a relay may fit your existing workflow, but an unverified protocol path can leave you with a setup that is either insecure or simply unable to connect.
Keep the stream key secret
YouTube describes stream keys as credentials used by an encoder to send a feed. Anyone who obtains a key may be able to send to the associated stream, so store it with the same care you would give another channel credential. Use a private configuration mechanism, restrict access to the people who need to maintain the stream, and avoid sharing it in general-purpose chat or screenshots.
If you use a configuration file, ensure it is not accidentally committed to a public repository or copied into a public example. Redact keys before sharing logs with a technician. A log may contain a full publishing address or other values that reveal the key even if the key was not deliberately included as a separate field. Review what you share rather than relying on a filename or folder being private.
If you suspect exposure, reset the key in Live Control Room. You will then need to replace the old value anywhere the outbound YouTube connection is configured, including a relay and any backup encoder that uses it. Resetting only in Studio while leaving a stale value in the relay will break that publishing path; updating only one of multiple encoders may leave another path failing later.
A key reset is a credential rotation, not a fix for every connection problem. If Studio shows no incoming feed, first identify which leg fails and inspect the relevant non-secret settings. Avoid circulating the replacement key as a quick troubleshooting shortcut. The invalid stream key troubleshooting guide can help distinguish a credential mismatch from other relay configuration problems.
Confirm the preview before going public
Start the encoder and allow the relay to publish. In Live Control Room, wait for the incoming preview and inspect the stream health indicators before starting a scheduled public broadcast. For a scheduled stream, YouTube’s guidance is to wait for the incoming preview and then use Go live in Studio when you are ready. A configured relay or a successful local publisher message is not a substitute for seeing the feed arrive at YouTube.
Check both picture and sound. Confirm that the intended scene or recorded material is playing, that audio is present and understandable, and that the stream is not showing a frozen opening frame. For a long-running devotional, ambience or study channel, let a representative portion play long enough to notice issues such as missing audio or an abrupt loop transition. Do not infer from a brief connection message that an all-night stream will behave correctly.
YouTube advises testing upload capacity and leaving headroom; its streaming tips recommend 20% headroom. The required bandwidth depends on the selected format and encoder settings, so consult YouTube’s current recommended encoder settings rather than carrying a single bitrate from one resolution, frame rate or codec to another. Its guidance covers supported codecs and settings such as keyframe interval and constant bitrate; use the current recommendations for the format you actually intend to send.
Test before the event, not at its public start. Watch the Studio preview while you check the relay and encoder status, and note which component reports a failure. If the preview is absent, investigate the two connection legs separately. If it appears but the stream health is poor, inspect the source, encoding settings and available upload capacity as well as the relay. A practical test should cover the actual content and audio path, not only a blank or silent test scene.
For a channel that needs to continue while your computer is off, decide who or what will observe the running broadcast and what the recovery procedure is if it stops. A local test can establish that the key and endpoint work at that moment; it cannot establish that every part of a longer operation will remain available. Document non-secret recovery steps, including where the stream settings are managed and how a key reset would be applied.
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
Where do I find my YouTube stream key in Studio?
Open YouTube Studio, choose Create, then Go Live, and select the Stream tab in Live Control Room. Create or select the stream, then copy its stream URL and key from the settings. Treat the key as a password and do not publish it.
What is the YouTube RTMP server URL?
Use the Stream URL shown in the selected stream’s Live Control Room settings. Studio may also provide an RTMPS endpoint; use the secure endpoint when the encoder or relay supports it. Do not assume a URL from an old setup or another channel is the right destination.
Can every Nginx RTMP setup push to YouTube over RTMPS?
No. Support depends on the module variant, version and build, and RTMP relay support alone does not establish RTMPS output support. Check the documentation for the actual module and test the outbound connection before relying on it for a broadcast.
Does a valid stream key guarantee the stream will work?
No. The endpoint, protocol, relay configuration, encoder output and channel status also matter, and YouTube must receive a usable feed. Confirm the Studio preview and stream health before going public.