To send a live encoder feed from a Google Cloud VM to YouTube, copy the event’s stream URL and key from Live Control Room, choose supported encoder settings and confirm the VM can sustain outbound traffic to the ingest endpoint. Then test the full path with representative video and audio before making the broadcast public; no individual bitrate, VM size or firewall rule guarantees a healthy stream.
The settings below cover the signal the encoder sends to YouTube, not every quality or resolution a viewer will receive. YouTube transcodes an incoming live stream for playback, so your job is to deliver a stable, supported input and watch the health indicators during the broadcast.
Collect the stream URL and key
In YouTube Live Control Room, create or select the event you intend to use, then find its stream settings. Copy the stream URL and stream key into the encoder’s streaming configuration on the VM. The URL identifies the ingest destination; the key associates the incoming feed with the channel or event. YouTube describes stream keys as the stream’s “password and address”, so handle them as credentials rather than ordinary setup notes.
Use the key for the correct event and channel. If your encoder allows separate fields for server URL and key, put each value in its intended field. Some software offers a combined URL field; check its documentation rather than improvising a format. Do not paste the key into a public issue, shared screenshot, shell history, recording, or chat. If a helper needs access, use an appropriate account or permission workflow rather than sending the key casually.
The official YouTube Help guide to managing live stream settings explains where stream settings and keys are managed. The interface may change, so use the current Live Control Room view rather than relying on an old screenshot. If you are preparing a prerecorded loop, the mechanics of assigning a key are also relevant to this YouTube stream key setup for a retail promo loop. A loop’s content workflow differs from a VM encoder, but the credential still needs the same care.
Before configuring the VM, record the event identity and the intended encoder profile somewhere private and accessible to the person operating the stream. Avoid recording the secret itself in a general runbook. If a restart is needed overnight, you want to know which event and profile to select without turning the written procedure into another copy of the key.
Protect or reset a compromised key
Treat a stream key as exposed if it appears in a public document, screenshot or log, or if you cannot establish who has seen it. Reset or replace it in Live Control Room, then update the encoder on the VM with the new value. The old key should no longer be the credential you rely on. Do this before the next broadcast where possible, and check whether other people or scripts still hold the old value.
A reset interrupts workflows that depend on the previous key until they are updated. Plan for this when the channel is live: decide whether to make a new key during a test window, update the encoder, and confirm that the new feed arrives before the next scheduled event. Do not post the replacement in the same place where the old one leaked. If the VM configuration is managed by a secret store or restricted configuration file, update that source and limit who can read it.
For shared channel operations, separate permission to manage live settings from casual access to a broadcast checklist. YouTube’s stream key and permissions guidance can help you think through which Live Control Room options are appropriate for the people involved. The useful principle is modest: give each operator the access they need, and make it possible to replace a key without searching through public or broadly shared notes.
Choose an ingest protocol and endpoint
YouTube recommends RTMPS for live ingestion. RTMPS is the encrypted extension of RTMP; do not confuse that recommendation with using unencrypted RTMP simply because an encoder calls both options “RTMP”. In the encoder, select the secure protocol if it is supported, then use the stream URL supplied for the event or the endpoint specified in current YouTube guidance. Do not substitute an address found in an old tutorial without checking that it applies to your stream.
YouTube’s current encoder settings and bitrate guidance is the primary reference for supported ingest choices. Confirm protocol and endpoint details there when setting up or changing the encoder. An encoder may label its fields as server, URL, ingest address or destination; map those fields to the URL and key from Live Control Room, not to a viewer-facing watch URL.
If your encoder does not support RTMPS, check whether an update or a different supported configuration is available before using a less secure route. That decision is not only about connection success: the stream key is a credential, and encryption protects the traffic carrying it. You do not need to open an inbound port on the VM merely to send the encoder’s stream outward. The connection begins from the VM, so focus on the VM’s outbound route and effective egress policy.
Set codec, frame rate, bitrate and keyframes
Choose settings as a group. YouTube lists H.264, H.265/HEVC and AV1 video, AAC or MP3 audio, constant bitrate (CBR), frame rates up to 60 fps, and a recommended two-second keyframe interval that should not exceed four seconds. Check the live settings page for current codec and HDR caveats before a specialised production. A codec that is supported by YouTube still needs to be supported by the encoder you are running and practical for the VM’s CPU or accelerator.
The bitrate depends on codec, resolution and frame rate; one “YouTube bitrate” does not fit every feed. The following examples are YouTube’s listed recommended H.264 ingest rates, not universal targets. The same official page includes minimums and separate guidance for other codecs, so select the row that matches your actual encoder output and verify the current values before deployment.
| H.264 ingest format | Listed minimum | Listed recommended rate |
|---|---|---|
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
| 2160p at 60 fps | 14 Mbps | 50 Mbps |
A minimum is not a promise of good results, and the recommended value is not a requirement that every channel must use. A static devotional image with spoken audio may not need the same visual detail as a fast-moving product demonstration, but the encoder still needs a compatible profile and enough throughput for the rate you choose. If you raise resolution or frame rate, reconsider both bitrate and the VM’s ability to encode in real time. For more context on making a practical resolution choice for a continuous visual, see what resolution to use for a 24/7 waterfall stream.
YouTube recommends leaving 20% bandwidth headroom above the stream bitrate. For a single feed, compare the planned encoder rate with measured, sustained outbound capacity and leave room above it; do not treat a speed-test peak as a sustained guarantee. For multiple feeds, add their outbound rates before considering headroom. A test performed while the VM is idle may not represent the conditions when encoding and other workloads are active.
YouTube automatically detects resolution and frame rate by default. If the workflow needs fixed values, YouTube says to create a custom stream key and enable manual settings under stream resolution. Set that only when you have a reason to control the ingest format and have tested it. Otherwise, automatic detection avoids adding manual choices that do not improve the production. Regardless of mode, the encoder’s keyframe interval should follow YouTube’s guidance; two seconds is the recommended setting and four seconds is the upper bound stated in its encoder guidance.
Check outbound connectivity from the VM
A Compute Engine VM needs a valid path to reach external systems. A VM with an external IP can communicate outward; a VM without one needs another configured outbound path, such as Cloud NAT. Google Cloud’s external IP and internet access overview describes relevant network paths. Confirm the actual configuration for this VM rather than assuming that an instance can reach the public internet because another instance can.
Then inspect the effective egress policy. Default VPC firewall rules permit outbound connections, but a custom VPC rule or an organisation-level firewall policy can change that. Check the network, subnet, tags or service account selectors involved and any hierarchical policies your organisation applies. You do not need to allow unsolicited inbound traffic to send a feed; avoid broadening ingress rules as a guess at a streaming fix.
A successful route check is only the first step. Your encoder must be able to resolve and reach the chosen ingest endpoint using the selected protocol and port, and the path must remain usable under the workload. If a connection fails, inspect the encoder’s own connection messages, VM route and firewall policy, DNS resolution and any outbound proxy requirements. Test with the real endpoint and protocol rather than inferring success from a generic ping, which may be blocked or may not test the same path.
Google Cloud documents VM bandwidth as dependent on machine type and routing, with per-flow and project-level egress constraints potentially relevant. The listed maximum is a ceiling under applicable conditions, not sustained throughput promised to your encoder. Google’s Compute Engine network bandwidth documentation is useful when estimating a candidate machine, but it cannot establish how your particular encode will perform in its region, network path and workload.
There is no responsible one-size VM recommendation without knowing resolution, codec, frame rate, encoding implementation, source complexity, region and whether you need redundancy. First confirm that the encoder can process the content in real time without saturating the VM. Then observe outbound capacity during a representative run and account for any project quota or per-flow restriction. If reliability matters, test under expected load and keep the headroom above the planned stream rate; do not size from a headline maximum alone.
Test the complete pipeline and monitor health
Before a public event, run a private or unlisted test using the same VM, encoder profile, network path and stream key arrangement intended for production. Include representative motion and audio. A still title card will not reveal the encoding load of a busy video, and silent footage will not show whether the audio source is connected, audible and correctly configured. If the eventual channel uses a long prerecorded loop, test a representative segment rather than just the first frame.
Check in sequence: does the encoder connect, does the preview appear in Live Control Room, does the audio meter respond, and do YouTube’s stream-health messages show problems? Observe the VM at the same time for sustained CPU or accelerator load, memory pressure, encoder lag and changing outbound throughput. A preview that appears once does not prove the stream will remain stable overnight. Repeat a test long enough to encounter the operating conditions that matter, including any scheduled source changes or restart procedure.
Use the test to change one variable at a time. If the picture drops frames, distinguish encoder overload from a network bottleneck before changing bitrate. If YouTube reports insufficient bitrate, check both the configured rate and the capacity actually available on the outbound path. If audio is missing, investigate the audio source and encoder track rather than increasing video bitrate. Changing several values at once can make a temporary improvement hard to explain or reproduce.
Keep a short handover record: event name, encoder profile, VM identifier, test outcome, known warnings, and who can reset the key. Do not include the key in the record. If a 24/7 broadcast will be operated unattended, make the restart and recovery steps clear to someone other than the person who built the VM. The practical purpose is not to claim that a checklist prevents every interruption, but to make a failure diagnosable without improvising under pressure.
During the public stream, watch YouTube’s stream-health indicators and messages, and periodically verify that the video and audio reaching the event are still what viewers should see. The health display reports YouTube’s view of the incoming stream; it does not replace checking the source content or VM workload. If the feed degrades, note the time and message, then compare the encoder logs, resource use and outbound path. That evidence helps you decide whether to lower the chosen format, address capacity, or correct an encoder setting.
The workload is different if you want a prerecorded file to remain on air without keeping an encoder running on your own machine. StreamNeo turns an uploaded video into a YouTube live stream, which removes the specific burden of keeping your local computer powered and connected for that loop; it does not replace checking the event, content and stream health.
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 RTMP instead of RTMPS?
YouTube recommends RTMPS, the secure extension of RTMP, for live ingest. Prefer it when your encoder supports it, and check YouTube’s current endpoint instructions rather than copying a URL from an old setup.
Should I open an inbound firewall port on the VM?
Usually, sending a stream is an outbound connection initiated by the VM, so an inbound rule is not the fix to try first. Check the VM’s route and effective egress rules, including any organisation-level policy, and avoid exposing extra inbound access without a separate requirement.
What bitrate should I use for a 24/7 stream?
Choose by codec, resolution and frame rate, then verify the current YouTube recommendation for that combination. Leave the recommended bandwidth headroom and test sustained outbound capacity under the same workload; a bitrate table cannot predict the throughput of your VM’s actual route.
Does a successful test mean the public stream will stay healthy?
No. A test confirms that the chosen path worked under the conditions observed, not that every later condition will match. Monitor YouTube’s stream-health messages and the VM during the live run, and keep a tested recovery procedure available.