A Hetzner Cloud server can run the video source and encoder for a continuous YouTube stream, but Hetzner is not the stream destination. YouTube supplies the ingest URL and stream key; your server sends a compatible live feed to that endpoint over the network.
The practical work is to check channel eligibility, choose an encoding approach and size the server and traffic for it, then test and supervise the feed. YouTube and Hetzner document their respective parts, but neither provides a tested Hetzner-to-YouTube recipe or a promise that a particular setup will run without interruption.
How the Hetzner-to-YouTube workflow fits together
Think of the setup as three pieces: a video source, an encoder or remuxer, and YouTube’s ingest service. The source may be a video file or a sequence of files stored on the virtual machine. The encoder produces a live-compatible stream, then sends it to YouTube using the URL and key created in Live Control Room.
Hetzner’s role is to provide a virtual machine and network connectivity. Its Cloud overview describes Cloud servers as virtual machines; it does not specify a minimum machine size for encoding video or a YouTube-specific setup. You need a public network interface for public internet access, and your cloud firewall must not prevent the server from making the required outbound connection. Do not infer from an available VM that a given video will encode smoothly on it.
A looped prerecorded channel and a live camera feed have different workloads. With a file that already matches the intended video and audio format, a remux may avoid some of the work of transcoding. If the source needs resizing, frame-rate conversion or a different codec, transcoding requires more processing. Actual CPU demand depends on the file, software, codec and settings, so test the combination you intend to run.
If you are moving a broadcast from a computer you keep at home, the home-PC-to-cloud transition guide can help you think through what changes when the machine is no longer in your room. The essentials here remain the same whichever host you use: YouTube must receive a valid feed, and you need a way to see whether it is still healthy.
Check channel eligibility before provisioning
First confirm that the YouTube channel can go live. YouTube’s getting started with live streaming guide says that a channel must be verified and must not have live-streaming restrictions in the previous 90 days. YouTube lists a minimum age of 16 for live streaming. If live streaming has not previously been enabled, activation may take up to 24 hours, so check this before planning a launch date rather than waiting until the server is configured.
These are account requirements, not server settings. Creating a VM or installing an encoder will not remove a restriction on the channel. Sign in to the correct channel and check its current status in YouTube Studio. Review YouTube’s current guidance as requirements can change, and resolve any account issue before proceeding with the ingest setup.
It is also worth deciding what you are broadcasting and whether your source material is appropriate for your channel and intended use. A continuous stream can remain live while nobody is watching, but that does not make its content, rights or account status exempt from YouTube’s rules. This guide addresses the technical path, not a guarantee of approval, reach or monetisation.
Create a stream and protect its key
In YouTube Live Control Room, create or schedule a stream and obtain its ingest URL and stream key. The URL tells the encoder where to send the feed; the key associates that feed with the broadcast. You enter both in the encoder configuration, following YouTube’s instructions for the selected ingest method.
Treat the stream key like a password. Do not put it in a public repository, a shared command transcript, a screenshot, or a support message that does not need it. If you use a server-side configuration file, restrict who can read it; if you use an environment secret, keep it out of logs and shell history. Rotate or replace the key through YouTube if it is exposed, and update the encoder configuration afterwards.
For a scheduled broadcast, check that the encoder is attached to the intended event rather than another stream. Keep a record of which file or playlist is intended for which event, but do not include the key in that record. If you see an invalid-key error, check for extra spaces, a stale key, a mismatched event or an incorrectly copied URL. The FFmpeg invalid stream key troubleshooting guide covers those checks in more detail.
Prepare the source and encoder on the server
Make the video files available to the VM and verify that they play from beginning to end. For a prerecorded channel, decide how playback should continue at the end of a file: restart the same file, move through a playlist, or stop and alert you. A playlist with an unexpected gap or an unreadable file can interrupt the programme even when the encoder process remains active.
FFmpeg is one possible software encoder when its build and the media suit the job. You may instead use another encoder compatible with YouTube’s ingest guidance. In either case, distinguish a remux from a transcode. A remux changes the container or packet handling without re-encoding the audio and video, which can reduce CPU work when the source already fits. A transcode changes the media stream and can make an incompatible source suitable, but adds processing load and creates more settings to validate.
YouTube’s encoder settings guidance lists RTMP and RTMPS ingest, H.264, H.265/HEVC or AV1 video, AAC or MP3 audio, constant bitrate encoding, and a recommended keyframe interval of two seconds, not exceeding four seconds. YouTube recommends RTMPS, the secure version of RTMP. These are YouTube’s published requirements and recommendations, not a ready-made FFmpeg command or a guarantee that a particular file will work.
Confirm the installed encoder build supports the codec you choose. Check the file’s actual codecs, resolution, frame rate and audio format rather than relying on its filename or container extension. For a loop, test both the transition from the end to the beginning and the behaviour when a playlist entry is missing. Do not copy a command from a guide without understanding how it handles looping, failures and the stream key.
If configuration is unfamiliar, first make a short test with a non-sensitive key and a private or unlisted broadcast as appropriate to your workflow. Keep placeholders in any notes or scripts you share. An example configuration should show where a secret is supplied without revealing the secret itself.
Check network access, settings and traffic
The VM needs public outbound connectivity to YouTube’s ingest endpoint. Check that the network and any cloud firewall rules allow the encoder to establish its outbound connection. Administrative access to the VM is a separate concern: allow only the access you need, and avoid opening unrelated inbound services in the name of making the stream work. Hetzner’s documentation describes general Cloud networking, not a special YouTube firewall profile; verify the rules for your own server and current product.
Select bitrate using YouTube’s table for the codec, resolution and frame rate you plan to send. For example, YouTube lists 5 Mbps minimum and 14 Mbps recommended for 1080p30 H.264; for 720p30 H.264 it lists 3 Mbps minimum and 8 Mbps recommended. At 1080p30, the table lists 4 Mbps minimum and 10 Mbps recommended for AV1 or H.265. These are encoder guidance values published by YouTube, not measurements of what your audience’s connection can receive. Use the current table for the exact format rather than treating these examples as universal settings.
A higher sustained bitrate consumes more outbound traffic. As arithmetic, 5 Mbps of video payload sustained for 30 days is about 1.62 TB in decimal units; audio and protocol overhead add to that. This is an estimate from bitrate multiplied by elapsed time, not a Hetzner allowance. Check the current traffic allowance and billing terms for the specific Cloud product and location you are considering. Do not assume a notification at a usage threshold will cap or stop traffic.
Compare the cost and capacity of the VM against both the encoding workload and the outgoing traffic. Location also matters: consider where your audience is, the available plan and its current included traffic, rather than selecting a region only for a larger allowance. Each independent output generally adds traffic, so a setup that sends to several destinations should be budgeted accordingly.
| Choice | What changes | What to check |
|---|---|---|
| Remux or transcode | Remuxing can use less CPU if the source already matches; transcoding adds processing work. | Test the actual file, codec and encoder build. |
| Lower or higher bitrate | Lower bitrate uses less outbound traffic; higher bitrate can carry more picture detail. | Use YouTube’s table and consider the audience and source. |
| One or several outputs | Additional independent outputs generally add egress and operational work. | Estimate total traffic and monitor each feed. |
| Cloud plan and location | Compute, included traffic and costs vary by product and location. | Check the current order details and terms for the exact choice. |
If you are still deciding whether to manage the machine yourself, compare the control and maintenance work with a continuous-stream service. YouTube’s encoder directory includes examples for continuous prerecorded streaming, but a listing does not mean YouTube has tested your custom Hetzner configuration. A managed route may reduce the work of keeping a machine and process configured; a self-managed VM gives you more direct control and leaves you responsible for updates, monitoring and recovery.
Test the feed before relying on it
Start with a short end-to-end test. Confirm that the source plays, the encoder connects to the expected YouTube stream, and the Live Control Room preview shows picture and sound. YouTube explicitly advises creators to test before starting a live stream and to monitor stream health. Check its current encoder tips as well as the status shown in Studio.
Test conditions that commonly fail outside a quick preview: the end of a loop, a playlist transition, audio that becomes silent, a file that cannot be decoded, a lost network connection, and an encoder process that exits. Check what YouTube displays when the feed drops and whether the encoder reconnects. A process being listed as running is not proof that the platform is receiving usable audio and video.
Monitor the encoder process, CPU, disk space and network traffic. Also check the stream’s health in Live Control Room, where you can spot a feed that is connected but has quality problems. The cloud-loop disconnection guide is useful if a stream drops after initial setup, though the underlying cause still needs diagnosis on your own system.
Before launch, test the complete path after a server reboot and after an encoder restart. Confirm that the source and configuration are available when the process starts, that the key is still valid, and that playback resumes as intended. These checks do not establish future availability; they reveal problems you can correct before the channel depends on the setup.
Plan for interruptions and recovery
A 24/7 stream needs a plan for what happens when something fails. A process supervisor can restart an encoder after it exits, but it cannot correct a bad key, a missing file, an account restriction or a network issue by itself. Configure any restart behaviour carefully so a broken process does not enter an endless restart loop without an alert.
Keep enough operational information to diagnose a failure: the time it began, whether the encoder was running, whether the VM had network access, and what YouTube showed. Logs should not expose the stream key. Set an alert for conditions you can act on, such as the encoder stopping, disk space running low or the stream no longer appearing healthy in Studio. Make sure you know how to sign in and reach the server if the usual access route fails.
A second machine or output can provide another recovery path, but it also adds cost, traffic and configuration that must be tested. Decide whether the value of that extra path suits your channel; do not describe redundancy as a guarantee. For some readers, keeping an operator available to intervene is more practical than building a complex failover setup.
If the work of keeping a server, key, media loop and restart path coordinated is itself the main risk, StreamNeo can remove that particular burden: you upload the video once, connect the YouTube stream key, and the broadcast can run without your own computer left on. That does not remove the need to choose suitable content or check YouTube’s current account and stream requirements.
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 YouTube encoder?
No. Hetzner Cloud provides virtual machines and networking; you supply and configure the media source and encoder, then send the feed to YouTube’s ingest endpoint. YouTube provides the stream URL and key in Live Control Room.
Which Hetzner server size should I use?
There is no universal size in the official documentation reviewed for this setup. The required capacity depends on whether you remux or transcode, the media format and the chosen settings, so test the exact workload on the plan you intend to use before relying on it.
Can I leave a prerecorded video running continuously?
A prerecorded source can be looped or played from a playlist, but you need to test end-of-file behaviour and transitions. Check that audio and video continue in the preview and decide what should happen if a file fails or the encoder stops.
Does this setup guarantee an uninterrupted stream?
No. A running VM does not establish that YouTube is receiving a healthy feed, and interruptions can come from the source, encoder, network, account or platform. Monitoring and a tested recovery plan can help you respond, but they do not guarantee uninterrupted broadcasting.