A continuous YouTube stream from Hetzner Cloud requires more than creating a virtual machine. You need a channel and event configured in YouTube Live Control Room, an encoder on the VM that sends a supported feed, and supervision that detects and responds to failures.
Hetzner provides the virtual machine and network options; it does not configure the encoder or guarantee that a process will recover. This guide takes you through the complete path, from channel eligibility to testing and ongoing operations.
Understand the four roles
Think of the setup as four separate jobs. YouTube controls whether your channel can go live and provides the ingest details. Hetzner supplies a virtual machine (VM) with an operating system and network connection. An encoder reads your media and sends a live audio/video feed to YouTube. Finally, supervision and monitoring help you notice and respond when a process, VM, network path or stream fails.
These jobs have different failure modes. A VM can be running while its encoder is stopped. An encoder can be running while YouTube reports an unhealthy input. A healthy input does not prove that viewers can hear the intended audio or that the right event is visible on the watch page. Treat the green light in one component as evidence about that component, not the whole service.
Before choosing a VM, decide what you are sending. If a finished video already has the resolution, frame rate and codecs you intend to use, an encoder may be able to pass its encoded audio and video through without converting them. If the source needs resizing, a codec change, overlays or mixing, the VM must perform more processing. That difference affects CPU demand, configuration and how quickly you can diagnose a problem.
A cloud VM can be useful when you do not want a desktop computer running at home or at a shop all night. It also moves responsibility to a machine you must configure and monitor remotely. If you are weighing that trade-off for a music channel, how to set up a YouTube lofi radio stream using a cloud server covers the broader cloud-streaming pattern.
Prepare YouTube Live Control Room first
Check that the channel is currently eligible to live stream before building the encoder setup. YouTube's eligibility guidance says the channel must be verified, must not have had live-streaming restrictions in the prior 90 days, and the person streaming must meet YouTube's minimum age requirement. Eligibility is account-specific and policies can change, so check YouTube's live-streaming eligibility requirements rather than assuming that an older live stream proves the channel is ready today.
In YouTube Studio, use Create, then Go Live, to open Live Control Room and create or select a stream. The exact screen labels can change. Choose the event and privacy settings appropriate to your channel, then locate the server URL and stream key for the encoder. YouTube describes these as the values you enter into the encoder to begin streaming; they are not credentials supplied by Hetzner.
Treat the stream key as a password. Do not put it in a public tutorial, screenshot, repository or command that will be saved in shell history. Restrict access to the account and configuration where you keep it. If someone else sees it, reset the key in Live Control Room and update your encoder with the replacement. A copied key can allow another encoder to send to the same stream, so do not paste it casually into support requests.
For a continuous channel, consider the event and archive plan before going live. YouTube says streams under 12 hours are automatically archived; that statement does not establish that an indefinitely running event will be archived in the same way. Check the current YouTube live-streaming and archiving guidance if a replay or local copy matters. One long event may reduce manual event changes, while scheduled shorter events may make archive and operational boundaries clearer. Neither choice removes the need to monitor the feed.
Create a Hetzner Cloud VM for the workload
In Hetzner Console, create a Cloud server and choose its server type, location, operating system image, networking and SSH key. Hetzner's server creation documentation describes these choices. Ubuntu is among the available Cloud operating system images. Add the SSH public key during creation where possible; Hetzner notes that adding one later through the Console is not available, although other methods can be used.
Choose the location for practical reasons such as your administration needs and the network path to your audience. Hetzner documentation offers general location guidance, not a YouTube-specific best region. A nearer location does not guarantee a better ingest route, so test the actual VM and feed rather than relying on geography alone.
Do not select a server size based on a universal streaming rule. Passing through an already encoded file can use substantially different resources from real-time transcoding, and overlays or audio processing add work. There is no single size established here as sufficient for every source and target format. Start with a configuration appropriate to the task, then watch CPU and memory under the real workload and resize if the encoder is consistently short of resources.
Connect to the VM using SSH and its public IP address. Keep inbound access limited to what you need for administration. If you use a Hetzner Cloud Firewall, its documented default blocks inbound traffic unless allowed and permits outbound traffic unless you set outbound rules. An encoder sending a feed to YouTube needs outbound connectivity; it does not require you to open inbound media ports on the VM simply because YouTube receives the feed. Review Hetzner's Cloud Firewall documentation and avoid relying on a fixed YouTube destination address unless current official documentation supports it.
You are responsible for the operating system, encoder installation, media files, key handling and updates. Keep the source file somewhere the encoder can read after a reboot, and verify disk space if you store local recordings or logs. A VM that can reach the internet but has lost its input file cannot provide the intended programme.
Install and configure an encoder
Install an encoder that can read your chosen media and send a stream to YouTube. FFmpeg is one possible implementation, but the command depends on the source, installed build, desired output and how you intend to loop media. Do not treat a copied one-line command as proof that looping, timestamps, audio and reconnect behaviour are correct for your file.
First decide whether you need stream copy or transcoding. With stream copy, the encoder forwards existing encoded tracks without decoding and re-encoding them. This can reduce CPU use, but only works when the tracks, timestamps and format are suitable for the planned output. Transcoding lets you change resolution, frame rate, codec or audio settings, but costs CPU and can overload an undersized VM. The encoder-overload troubleshooting guide explains why processing capacity matters even when the source looks simple.
Use YouTube's current encoder guide as the source of truth for ingest requirements and the bitrate table for the selected resolution and frame rate. YouTube recommends RTMPS, constant bitrate (CBR), and a two-second keyframe interval, with the interval not exceeding four seconds. Its supported codec choices include H.264, H.265/HEVC and AV1. These settings are not a reason to force a codec that your encoder or playback workflow does not handle; match the output to the current guidance and test it.
The encoder needs the YouTube server URL and stream key. Keep the key out of world-readable configuration files and command histories. Use a restricted account and file permissions for any configuration file that stores it, and do not include the key in logs you share. How you supply secrets depends on the encoder and operating system, so validate that your method remains in place after restart without exposing the key to other users on the machine.
Looping also needs deliberate handling. Confirm that the encoder reaches the end of the file and returns to the start without a gap, frozen timestamps or silent audio. If you are combining files into a playlist, test transitions and ensure each source has compatible track settings. A loop option addresses the media sequence; it does not by itself prove that the encoder will reconnect after a network interruption or restart after a crash. For connection symptoms, use the checks in troubleshooting RTMP connection errors in an FFmpeg YouTube stream.
Connect the encoder to YouTube
Configure the encoder with the server URL and stream key shown for the selected YouTube stream. YouTube's encoder setup instructions explain where those values go and describe supported encoder settings. YouTube recommends RTMPS; choose it where the encoder supports it and the Live Control Room configuration provides the appropriate endpoint. Do not guess at endpoint addresses or copy an old URL from an unrelated guide.
Set the output resolution, frame rate, bitrate, codec and keyframe interval to align with YouTube's current recommendations and your source. A high bitrate is not automatically better: the sending connection needs stable capacity above the stream's total bitrate. YouTube recommends 20% reserve above the total stream bitrate. If your source includes separate audio and video tracks, account for their combined rate, and if you plan a backup feed, include it in the network budget as well.
Once connected, inspect the Live Control Room preview and stream health indicators. Confirm the right picture, the expected audio, and a stable signal before making the event public or relying on it. A successful connection message means the encoder reached YouTube; it does not verify that the programme is composed correctly or that the audience can watch it as intended.
Supervise the process and plan for failures
A process supervisor can start the encoder at boot and restart it after a process exits unexpectedly. On a Linux VM, systemd is one possible tool, but it is a choice rather than a YouTube or Hetzner requirement. Configure the service around your actual command and files, run it with limited permissions, and decide how restart attempts should be handled. A restart policy cannot repair a missing file, invalid stream key, full disk or blocked network path.
Plan for a server reboot as a separate test. The encoder should start only after its configuration and media are available, and the service should report useful failure information. Avoid suppressing errors so thoroughly that a repeated crash looks like normal operation. Keep logs sufficiently long to diagnose recurring faults, while avoiding secrets such as the stream key.
Monitoring should check more than whether the VM answers SSH. Track the encoder process, CPU and memory pressure, disk space, network availability and YouTube's reported stream health. Decide how an alert reaches a person who can act on it. For a small channel, that may be an email or phone notification; the important part is that an alert is noticed and someone knows whether to restart, inspect the source or replace the key.
Write down a simple recovery sequence before leaving the stream unattended: check the Live Control Room status, inspect the encoder log, confirm that the media remains available, and verify that the key has not changed. If the feed is still unhealthy after a process restart, investigate the underlying condition instead of repeating restarts without a diagnosis. A more detailed reconnect checklist is available in how to fix OBS reconnect attempts that fail during a YouTube stream, though the exact controls differ when you use a command-line encoder.
StreamNeo can remove the burden of keeping a self-managed VM and encoder process configured for a file-based channel: you upload a video once, enter the YouTube stream key, and the stream runs without your computer left on, with monitoring and automatic restarts if it drops. It is YouTube-only, so it does not replace this VPS workflow if you need your own server, another platform, or custom processing.
Test the full feed and keep it observable
Test before treating the setup as continuous. Send a representative feed and watch the Live Control Room preview for enough time to see the loop and any transitions. Check audio at the beginning and at a transition, especially if the video is a devotional programme, music station or ambience loop where a silent gap changes the experience. Confirm the public watch page and privacy setting from a viewer's perspective.
Then test failure behaviour deliberately while you can observe the result. Stop and start the encoder, reboot the VM, and confirm that the process supervisor behaves as configured. A controlled test shows whether the machine starts the service, whether the file path still works and whether YouTube receives a healthy feed again. It does not establish that every future network or platform interruption will recover automatically.
Check resource use during the actual output rather than only while idle. If CPU stays high or the encoder reports dropped frames, reduce processing demands or adjust the VM and output settings. If the feed is stable locally but YouTube reports an unhealthy signal, compare the output settings with current ingest guidance and inspect the connection. If YouTube reports a healthy stream but a viewer hears no sound, investigate the source and audio track rather than changing the VM firewall.
Keep a short operating note with the event identity, where the media lives, how the encoder starts, how to reach the VM, where logs are kept, and who should be alerted. Do not put the stream key in that note unless it is stored in a suitably restricted secret store. If a key is rotated, update the encoder and verify a fresh preview before considering the change complete.
The archive plan is part of testing too. YouTube's statement about automatic archives applies to streams under 12 hours; do not assume an indefinitely running event will leave a complete replay. If you need a replay, assess whether scheduled events or a separate local recording suit the channel, and consult current YouTube guidance before relying on a particular archive behaviour.
For a self-managed deployment, the trade-off is control in exchange for operational work: you choose the VM, encoder and recovery procedures, then own their testing.
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
Does Hetzner provide a ready-made continuous YouTube stream?
No. Hetzner provides a Cloud VM and configuration options, but you still need to prepare YouTube Live, install and configure an encoder, and supervise the process. The provider does not guarantee that your encoder will stay running or recover after a fault.
Which Hetzner server size should I choose?
There is no single size that suits every stream. Passing through an encoded file takes a different workload from transcoding, overlays or audio processing; monitor the VM under the real workload and adjust it if resources are constrained.
Will a 24/7 YouTube event be archived in full?
Do not assume so. YouTube says streams under 12 hours are automatically archived, but that does not establish archive behaviour for an indefinitely running event. Check current YouTube guidance and plan for shorter events or a separate recording if a replay matters.
What should I do if the stream stops?
Check Live Control Room stream health, then inspect the encoder process and its logs, file availability, key and network path. A supervisor may restart a crashed process, but repeated failures need diagnosis; a running VM alone does not prove that the stream has resumed.