A Google Cloud Compute Engine VM can run the encoder or relay that sends your video to YouTube Live. YouTube provides the ingest address and stream key; the VM supplies the continuously running process between your media file and YouTube.
The difficult part is not starting one broadcast. It is keeping the encoder alive after a reboot, detecting a failed connection, understanding what Google Cloud is charging for, and testing recovery before you leave the stream unattended.
What the VM does in a YouTube stream
The basic arrangement has three parts: your media, the VM, and YouTube Live. Your media might be a permitted video file, a playlist, a camera feed or another live source. The encoder on the VM reads that source, converts it into the required output, and sends the result to YouTube over RTMP or RTMPS.
YouTube does not play a file directly from the VM simply because the file exists there. An encoder process has to open the file, produce video and audio packets, and maintain the connection to YouTube. For a looping devotional video, for example, the process might reach the end of the file and open it again. For a local news loop, it might read a folder or playlist and move to the next item.
YouTube Studio supplies two values that matter here: the stream URL and the stream key. The encoder uses both. Treat the key as a password. Do not place a real key in a public Git repository, a screenshot, a shared support message or a startup script that other users can read. YouTube documents how to reset a compromised key, and says that a channel owner or manager can do so through the relevant controls.
The VM therefore hosts the sending process; it does not replace YouTube's Live Control Room. You still need to create or select the stream, choose the visibility and other YouTube settings, check stream health and decide what viewers should see if the source stops.
A VM is useful when the source and encoder need to run without your home computer staying switched on. It also gives you a place to manage a service, view logs and restart a process remotely. It is not automatically a reliable 24/7 system. Reliability comes from the process design, supervision, monitoring, testing and a recovery plan.
If your source is a completed event rather than a permanent station, the workflow in how to rebroadcast a prerecorded event continuously may be a better starting point than designing a general-purpose relay.
Prepare a Compute Engine VM
Start by deciding what the VM actually has to do. If your media is already encoded and the process only needs to repackage or relay it, the resource requirement may differ from a job that converts video in real time. Resolution, frame rate, codec, filters, audio handling and the number of simultaneous outputs all affect the workload.
Do not select a machine type because it is commonly mentioned in a tutorial. Google Cloud does not provide one universal VM size that is suitable for every stream. A configuration that handles a low-motion 720p loop may not have enough CPU for a higher-resolution source, a different codec or several filters. Test the intended workload on the configuration you plan to keep.
In the Google Cloud Console, create a Compute Engine VM and choose:
- A Linux image that supports your encoder and service manager.
- A machine configuration with enough CPU and memory for the actual encoding or relay work.
- A region that suits your audience, source location and operational requirements.
- A boot disk large enough for the operating system, encoder, logs and media you intend to retain.
- Access controls that limit who can connect to the VM and read the stream configuration.
A persistent disk is not the same thing as a backup. If the media file is important, keep a separate copy and know how you would replace it. Also decide whether the VM should be reachable only for administration or whether it needs any other public access. A YouTube-bound encoder normally needs outbound connectivity, but that does not mean the administration interface should be open to everyone.
Google documents that a startup script is a file containing commands that run when a VM boots. You can use one to install packages or start preparation commands, but do not treat it as the entire reliability design. Keep the script repeatable, avoid putting a live stream key directly into a broadly readable file, and make failures visible in logs.
For a first deployment, make the smallest useful change at each stage. Create the VM, connect to it, confirm that the intended media is present, install the encoder, run a short manual test, and only then add automatic startup and restart behaviour. This makes it much easier to distinguish a media problem from a permissions problem or an ingest problem.
Run a persistent encoder process
An encoder launched in an SSH terminal is not a persistent service. It may stop when the session closes, when the terminal disconnects or when the process encounters an input error. Use a service manager such as systemd, or another supervisor that you understand, so the encoder has a defined start command, environment, log destination and restart policy.
A practical service design should answer these questions:
- Which user runs the encoder, and can that user read the media and configuration but not unrelated files?
- Where is the stream URL and key stored, and who can read them?
- What happens when the input file ends, disappears or becomes unreadable?
- What happens when YouTube rejects the connection or the network path drops?
- How are standard output, error output and exit codes recorded?
- Does the process start after a VM reboot, and does it restart after an encoder failure?
For a looped file, test the transition at the end of the file rather than assuming it will be seamless. Some inputs have a different duration in their audio and video tracks. Some files contain metadata or codecs that the encoder accepts at first but does not handle correctly during a repeat. Watch the output during several transitions and inspect the logs.
If you use FFmpeg, the exact command depends on the input format and the output you want. A command copied from another machine can fail because its filters, codec support, file path or audio layout differs. The FFmpeg on Ubuntu YouTube streaming guide is useful for the encoder side, but you should still validate the command on your own VM and with your own media.
The output should normally use a constant bitrate mode where YouTube recommends it, with a codec, frame rate, resolution and audio format supported by the current YouTube encoder guidance. If the VM is encoding in real time, watch CPU usage during the hardest part of the source. A process that survives a quiet section may fail when the picture becomes more complex.
A service manager can restart a process, but repeated restarts can also hide a configuration error. Add a sensible delay between attempts, retain enough logs to see the pattern, and alert yourself if the process enters a restart loop. Automatic restarting is useful only when it is paired with information about why the process stopped.
Configure YouTube Live ingest
Open YouTube Studio and use the Live Control Room to create or select the broadcast. Copy the stream URL and key into the protected encoder configuration. YouTube's official encoder settings guidance covers the current protocol, codec, bitrate, frame-rate and keyframe recommendations. Check that page again when you change the output rather than relying on a remembered setting.
YouTube recommends RTMP or RTMPS for encoder streaming. RTMPS encrypts the connection through Google's servers. Use the protocol and address shown for the stream, not an address copied from an unrelated tutorial. Keep the stream key out of public examples. If you believe it has been exposed, reset it and update the VM configuration before reconnecting.
For H.264 at 1080p and 30 frames per second, YouTube's current listed recommended video bitrate range is 5–14 Mbps. For H.264 at 720p and 30 frames per second, the listed range is 3–8 Mbps. These are YouTube ingestion recommendations, not a promise of picture quality, a VM sizing rule or a monthly network cost. The correct choice depends on the selected codec, resolution, frame rate, content and the connection available to the encoder.
YouTube recommends constant bitrate and a keyframe frequency of two seconds, with the interval not exceeding four seconds. It lists H.264, H.265 and AV1 options where supported, and AAC or MP3 for audio. Use the current YouTube table for the codec and resolution you have selected rather than mixing settings from different examples.
The VM needs enough outbound capacity for the selected stream, but a high network speed alone does not prove that the encoder can produce the stream. A real-time transcode can be CPU-bound while a direct relay may be limited by the source or the network path. Check both sides.
Run a short private or unlisted test before making the channel public. YouTube says to test before starting a live stream and recommends running a speed test for the upload bitrate. Include the same kind of motion and audio that the final channel will contain. A still image with quiet audio is not a meaningful test for a music station or a news loop with frequent scene changes.
Monitor the stream and the VM
Monitoring should cover both the local process and YouTube's view of the broadcast. On the VM, check whether the encoder is running, whether it is reading the intended input, whether CPU and memory remain within safe limits, and whether the logs show reconnects, dropped input, broken pipes or repeated restarts.
In YouTube Live Control Room, check the stream preview, stream health messages and incoming video and audio. A process can be running while YouTube receives no usable data. Conversely, a brief ingest interruption may be recovering while the local process still appears active. These are separate observations and should not be confused.
Create a simple operating check that you can repeat:
| Area | What to check | What a failure may mean |
|---|---|---|
| Encoder process | The service is active and has not entered a restart loop | A bad command, missing file or resource pressure |
| Input | The file, playlist or live source is available | A path, permission, storage or source problem |
| Output | Packets are being sent and reconnect attempts are visible when expected | An endpoint, key, protocol or network problem |
| YouTube | Preview and health indicators show received video and audio | Invalid settings, ingest rejection or an output mismatch |
| VM resources | CPU, memory, disk space and logs remain usable | An undersized configuration or uncontrolled log growth |
Do not monitor only viewer availability. A public watch page may continue to load while the broadcast is behind, frozen or missing audio. Check the actual live control interface and keep a record of the time and symptom when something fails.
Set a disk policy for logs. Continuous services can fill a small boot disk if every reconnect writes a large trace. Rotate logs, retain enough history to diagnose a failure, and remove media you no longer need. Also confirm that a full disk does not prevent the service manager or operating system from working.
For unattended channels, an external check can be useful, but it should not blindly restart the VM whenever a page looks unusual. First establish what a failure looks like and how long a normal reconnect takes. A monitor that restarts a healthy encoder during a brief delay can create more interruptions than it prevents.
If YouTube shows a stream as offline immediately after FFmpeg starts, compare the local logs with the ingest settings and the control-room messages. The troubleshooting steps in why an FFmpeg YouTube stream can show offline after starting can help you separate an encoder exit from a YouTube configuration issue.
Estimate costs from your configuration
There is no honest single monthly price for this setup without knowing the VM's region, machine configuration, disk, runtime, media storage, outbound traffic assumptions and any other Google Cloud services attached to the project. A VM that only relays an already encoded stream is a different cost and resource question from one that performs continuous real-time encoding.
Google states that Compute Engine pricing varies by resource configuration, region and usage. A continuously running VM can incur compute charges, while the boot disk and applicable network charges are considered separately. Use the Google Cloud pricing calculator with the intended configuration rather than multiplying a tutorial's example by a month.
Google's VPC pricing documentation places Compute Engine traffic to YouTube in a no-charge data-transfer category. That does not make the VM free. It does not remove VM runtime charges, disk charges or other applicable costs, and the category and pricing documentation should be checked before you commit to a long-running setup.
Google's Compute Engine product overview listed, as accessed in 2026, a free tier involving one e2-micro VM instance, up to 30 GB of standard persistent disk and up to 1 GB of outbound data transfer per month. This is not evidence that a 24/7 stream will fit within the allowance. Eligibility depends on current terms, regions, resource use and traffic, so confirm the current offer on Google's site before relying on it.
Build the estimate from your actual design:
- Select the region and machine configuration you intend to run.
- Add the boot disk and any additional persistent storage.
- Set the VM runtime to continuous operation if that is the plan.
- Consider the source upload, YouTube-bound traffic and any other egress separately.
- Include logs, snapshots, static addresses or other resources only if you will use them.
- Check the result against billing alerts and a budget in the Google Cloud project.
A cost alert is not a hard spending cap. It tells you that usage may be approaching a threshold, but it does not necessarily stop a service. Review the billing account, quotas and permissions before giving the project unattended access to paid resources.
Plan for restart limits and recovery
A Compute Engine VM can reboot because of maintenance, an operator action, an operating-system problem or a resource failure. The encoder can also stop while the VM remains healthy. Your recovery plan must cover both cases.
Use boot-time startup to make the service return after a VM boot, and use process supervision to handle an encoder exit after the VM is already running. Then test both paths deliberately: stop and start the encoder, reboot the VM, remove and restore the test input, and simulate a temporary network failure if your environment allows it. Record how long recovery takes and whether YouTube receives a new or continuing broadcast state.
Do not confuse Google's separate Live Stream API with a user-run encoder on Compute Engine. Google's Live Stream API quotas and limits state that live stream sessions last for 24 hours after a channel starts, after which the channel may be restarted in the relevant streaming states. That statement applies to a channel in the Live Stream API. It does not establish a 24-hour limit for an encoder process running on a VM and sending directly to YouTube.
The distinction matters because the word “24/7” can describe several different designs. In this guide, the VM is hosting a process that sends to YouTube. It is not proof that every Google Cloud video service, YouTube broadcast state or encoder workflow can run without intervention for an unlimited duration. Check current YouTube and Google Cloud guidance when you change architecture.
Keep a recovery note outside the VM containing the project, instance, media location, service name, YouTube stream identity and the safe procedure for rotating the key. Do not store the key in that note unless it is protected appropriately. If the VM is lost, you should be able to recreate the setup without guessing, while still keeping the credential private.
If you would rather avoid maintaining a VM, an uploaded file can be sent to YouTube without leaving your personal computer running through a managed workflow. StreamNeo removes the specific burden of keeping the encoder process, boot recovery and cloud host running yourself: upload the file once, add the YouTube stream key, and the channel is operated from the cloud with monitoring and automatic restart handling.
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 a Google Cloud VM loop a video to YouTube Live?
Yes. The VM can run an encoder that reads a permitted media file or playlist, loops or advances through it, and sends the output to YouTube's ingest endpoint. You still need to configure the YouTube broadcast, protect the stream key and test the loop transition with the actual media.
Which Google Cloud VM size should I choose?
There is no universal answer because the workload changes with codec, resolution, frame rate, filters, audio and whether the VM encodes or only relays. Start with the smallest configuration that can be tested against the real workload, then watch CPU, memory, logs and stream health before leaving it unattended.
Is a startup script enough for a 24/7 stream?
No. A startup script can run commands when the VM boots, but it does not by itself prove that an encoder will restart after an application failure or that anyone will notice a bad input. Use process supervision, protected configuration, logs, monitoring and deliberate reboot and reconnect tests.
Does Google's 24-hour Live Stream API limit apply to this VM setup?
Not on the evidence of that API documentation. The stated 24-hour session rule is for a channel in Google's separate Live Stream API, whereas this design runs an encoder on Compute Engine and sends directly to YouTube. Treat the workflows separately and check the current official guidance if you change services.