A Hetzner Cloud VPS can run FFmpeg and send a prepared video, playlist or generated feed to YouTube Live. The right server depends on what FFmpeg must do: copying a compatible encoded stream has a different CPU workload from transcoding it in real time.
The VPS is one part of the path, not a guarantee of uninterrupted broadcasting. You also need a suitable source, YouTube’s current ingest credentials and encoder settings, enough outbound traffic allowance, and a way to notice and recover from failures.
Map the path from media to YouTube
The basic flow is source media on the server, FFmpeg reading and packaging that source, and an outbound connection carrying the result to YouTube Live. YouTube receives the stream at an ingest URL using a stream key associated with your broadcast. Viewers watch on YouTube; the VPS is the encoder and sender, not the viewing destination.
Your source could be one long video, a set of files, a camera or remote feed, or a scene generated by another process. Each brings different failure points. A single file can end unexpectedly, a playlist can have gaps or incompatible formats, and a live input can disappear independently of FFmpeg. Decide what the stream should show after each item ends or an input fails before choosing command-line options.
FFmpeg can either pass through compatible encoded audio and video, often called stream-copying, or decode and encode the media again. Copying avoids the main encoding work and preserves the source’s existing characteristics. Transcoding lets you change codec, resolution, frame rate or bitrate, but it uses CPU and must keep up with playback in real time. A VPS that handles one case well may struggle with the other.
For a rotating collection of recordings, the source-management problem matters as much as the encoder. A schedule or playlist can define order and transitions; using a JSON schedule to rotate videos across channels is a useful comparison if you need predictable rotation rather than replaying a single file.
Prepare the Hetzner server and media input
Start by choosing the Hetzner Cloud product, location and operating system that fit your workload and operating preferences. The available plans and resource classes change, so check the current plan details, traffic allowance and any public IP charges on Hetzner’s own pages before ordering. Hetzner describes shared-resource and dedicated-resource server classes; its dedicated CPU products are positioned for CPU-intensive workloads. That distinction is relevant if you need to transcode, but it does not tell you in advance which size your exact command requires.
After provisioning, update the operating system and install FFmpeg using a trusted package source or a build you have verified. Check that the installed FFmpeg has the input demuxer, codecs and output protocol support you need. The command ffmpeg -version identifies the build, while ffmpeg -protocols and ffmpeg -codecs can help you inspect available features. Package versions and build options differ, so do not assume that a flag or codec documented elsewhere is available on your server.
Before uploading a large file, inspect it. Confirm its duration, resolution, frame rate, video and audio codecs, and whether the audio is present throughout. FFprobe, distributed with FFmpeg, can report stream details. A file that appears to play normally on a desktop may still have an unusual codec, variable frame rate or audio layout that needs handling for a stable live output.
Make sure the source is in a location FFmpeg can read reliably and that the filesystem has room for any additional files or recordings you intend to keep. If you use a playlist, test every entry, not only the first one. Paths with spaces, missing files, permissions and a file that ends sooner than expected can all stop or alter the feed. The appropriate loop or playlist mechanism depends on the media and installed FFmpeg build; test the exact input arrangement rather than pasting a generic loop command into production.
For an existing encoded file, stream-copying may be appropriate if its codecs, container and stream properties suit YouTube’s current requirements. If you need a different output format or want to standardise mixed source files, transcoding may be needed. That choice affects both command design and server sizing. If your goal is high-resolution pre-recorded playback, see the separate considerations in this guide to streaming pre-recorded video in 4K at 60 fps; a higher output mode changes the encoding and traffic questions, not just the picture size.
Get the ingest URL and stream key from YouTube
Open YouTube Live Control Room and create or select the live stream you intend to run. YouTube’s encoder setup instructions explain how to obtain the stream URL and stream key. FFmpeg needs both to send video to your channel. Use the current values displayed for that stream rather than relying on an old saved URL or a key copied from a different broadcast.
Treat the stream key like a password. Anyone who obtains it may be able to send a broadcast to the associated stream. Avoid putting it in a public script, repository, screenshot or shared support log. A command entered directly in a shell can also remain in shell history, depending on your setup. Restrict file permissions, use a private configuration method where possible, and redact the key before sharing diagnostics.
YouTube recommends RTMPS, the encrypted extension of RTMP, for encoder ingest. Its current encoder settings guidance covers protocols and settings; use the URL and protocol provided for your stream and confirm that your FFmpeg build supports them. RTMPS protects the connection in transit, but it does not protect a key that has been exposed in a script or log.
Before going live to an audience, use YouTube’s preview and status messages to check that the signal is arriving as expected. Confirm both moving video and audible sound. A process that has started successfully is not proof that YouTube has received a compatible feed, and a healthy preview is a more useful deployment check than simply seeing FFmpeg print output.
Choose FFmpeg settings for the workload
Choose settings around the source, the output you want and YouTube’s currently displayed requirements. Resolution and frame rate influence both the encoder work and the amount of data sent. Codec choice and bitrate affect compatibility, quality and traffic. The YouTube encoder settings page lists recommendations by format and mode; use the row that actually matches the output you plan to send rather than treating one bitrate as universal.
For example, YouTube’s current H.264 guidance lists a recommended video bitrate of 14 Mbps for 1080p at 30 frames per second, and 8 Mbps for 720p at 30 frames per second. Those figures are for those specific H.264 modes and are not server sizing recommendations. The same page distinguishes minimum from recommended rates and provides separate guidance for other codecs and frame rates. Check the current table and the settings shown for your own stream before configuring FFmpeg.
YouTube’s guidance calls for constant bitrate (CBR) and a keyframe interval of two seconds, with a four-second maximum. FFmpeg options to achieve those properties depend on the chosen encoder and build. In a stream-copy setup, you cannot necessarily impose the same encoding controls as when you encode afresh; the source’s existing properties may determine what reaches YouTube. Test the actual output in Live Control Room.
| Choice | What changes | When it may fit |
|---|---|---|
| Stream-copy | Little or no video encoding work; source properties remain | A compatible source already has the required codec and output characteristics |
| Transcode | CPU is used to decode and encode; output can be adjusted | Sources need a different codec, resolution, frame rate or bitrate |
| RTMP | Broadly used ingest protocol; encryption is not provided by RTMP itself | Only where the selected encoder or endpoint requires it |
| RTMPS | Encrypted ingest connection | YouTube recommends it when supported by the encoder and endpoint |
Do not select a VPS by a rule such as “one stream needs this many cores”. The CPU demand of a software transcode depends on the input codec, output codec, resolution, frame rate, filters and encoder settings. Other work on the server and the resource class also matter. Begin with a representative test of the exact source and settings, then observe CPU use over time and check whether FFmpeg is keeping pace with real time. Memory, disk and network conditions matter too, but a CPU test is particularly important when encoding.
If the workload is a simple stream-copy and the server’s other resources remain available, shared CPU may be sufficient. If real-time encoding consistently competes for CPU, dedicated CPU resources may be worth evaluating. Neither class guarantees uninterrupted service. For a different comparison of encoder control and operating effort, read OBS versus FFmpeg for an always-on stream; the relevant choice depends on whether you need FFmpeg’s command-line workflow and can maintain it.
Start and monitor the stream
First run the command in a controlled test and watch both FFmpeg’s output and YouTube Live Control Room. Check that the preview is moving, audio is present, and YouTube does not report a persistent ingest or encoding issue. Test with representative movement and sound: a static image may hide problems that become visible in the actual programme. YouTube recommends testing the encoder and monitoring stream health before relying on a broadcast.
A terminal session is not a deployment plan. If the SSH connection closes, the machine reboots, or FFmpeg exits, the stream may stop. Run the process under a service supervisor such as systemd, or another process manager you understand. Configure an intentional restart policy, capture logs, and know how to inspect the service state. Restarting on failure is useful, but rapid repeated failures should create an alert or investigation rather than an endless loop that nobody notices.
Logs help distinguish a file read error, encoder overload, network failure and rejected ingest. Keep enough detail to diagnose those issues, but ensure the stream key is not captured in plaintext. Check CPU, memory, disk space and outbound network use during the test and after deployment. Set an alert path you will actually see, especially if the channel matters overnight or during a scheduled event.
A reconnect option in FFmpeg can help with some network interruptions, depending on the protocol and build. It is not a replacement for process supervision, and a process restart does not necessarily restore the intended content position or YouTube session in the way you expect. Test the recovery path deliberately: stop the process, restore it, and observe what appears in Live Control Room. Document how to restart safely and how to rotate the key if it is exposed.
A continuous broadcast also has consequences for archiving. YouTube says live streams under 12 hours are automatically archived; do not assume a longer, uninterrupted broadcast will become one complete replay. Check YouTube’s current guidance and make a separate recording plan if you need a complete archive. Recording locally or keeping source files introduces its own storage and recovery requirements.
Account for outbound traffic
The VPS sends data continuously to YouTube, so estimate egress from the actual output bitrate and operating schedule. A useful first estimate is bitrate in megabits per second multiplied by seconds streamed, divided by eight to get bytes, with unit conversion applied. This is an estimate, not a bill: audio, protocol overhead, reconnects and other server traffic add to it.
As an illustration, a 14 Mbps video stream running for 30 days sends about 4.54 decimal terabytes of video data before audio and protocol overhead. This is arithmetic using YouTube’s recommended H.264 1080p30 video bitrate, not a published usage figure from YouTube or Hetzner. A 720p30 stream at the listed 8 Mbps video recommendation would use less video traffic, but the total still depends on audio, overhead and how continuously you run it.
Hetzner’s traffic documentation lists 20 TB of included traffic for EU CX, CPX and CAX Cloud Servers, and different plan-based allowances for US and Singapore locations. Its billing information also explains that outgoing traffic can be billed when included traffic is exceeded; notifications at stated usage thresholds are warnings, not automatic traffic caps. These details are product- and location-dependent and may change, so verify the exact allowance and overage terms on Hetzner’s traffic page and billing pages before estimating cost. Do not apply the EU allowance to another location or product by assumption.
Compare the resulting estimate with the plan you intend to use, and include other outbound use from the server. If you operate multiple channels from one machine, estimate their combined egress. A lower bitrate can reduce traffic, but it is a quality and viewing-condition decision, not merely a way to fit a plan. If the stream’s output settings or schedule change, revisit the calculation.
Check reliability and recovery points
“24/7” describes the intended schedule, not a promise that the broadcast cannot break. There are several separate components: the server, operating system, FFmpeg process, source files, network path, YouTube ingest and YouTube’s live service. A successful check of one component does not establish that all the others are working.
Hetzner’s service agreement describes a commercially reasonable effort towards 99.9% monthly availability for an individual Cloud Server. That is a statement about the Cloud Server service under the agreement, not a guarantee that your FFmpeg application or YouTube broadcast will remain continuous. Maintenance, process exits, source problems, network interruptions and YouTube-side issues can each affect the stream. Read the current agreement and understand its scope rather than treating an availability figure as an application-level promise.
Write down recovery steps while the setup is still in testing. Include how to check the service, where logs are, how to confirm the current preview, how to restart FFmpeg, and how to respond if the key is compromised. Decide who receives alerts and what should happen if a source file becomes unavailable. If a playlist is important, retain a tested fallback item or a clear procedure for restoring the source rather than assuming the encoder can solve missing media.
Keep a separate copy of important media and configuration, but do not back up secrets in a way that makes them broadly accessible. Revisit the setup after changing FFmpeg versions, source formats, resolution, frame rate or server plan. A command that worked for one file and one build can behave differently after those changes. Retest the preview, CPU headroom and traffic estimate before treating the new configuration as routine.
A self-managed VPS gives you control over FFmpeg, the operating system and the recovery process, while leaving that maintenance with you. If you would rather not keep a computer or VPS process running and supervise it, StreamNeo removes that specific operating burden by taking an uploaded video and running it as a YouTube live stream while your own computer is off. It is YouTube-only, so it does not replace a VPS when you need custom FFmpeg processing or another destination.
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 loop a video from a Hetzner VPS to YouTube Live?
Yes, if FFmpeg can read the source and send an output that YouTube accepts using the current ingest URL and key. The right looping or playlist method depends on the files and FFmpeg build, so test the complete sequence and its transition behaviour before relying on it.
What size Hetzner VPS do I need?
There is no universal size for this workload. Test the exact source and command: stream-copying a compatible file avoids real-time video encoding work, while transcoding depends heavily on the codec, resolution, frame rate and options. Observe CPU and other resource use during a representative run, then choose a plan with appropriate headroom.
How much traffic does a 24/7 stream use?
It depends mainly on the output bitrate and how long the stream runs, with audio and protocol overhead adding to the total. As a reference calculation, 14 Mbps of video for 30 days is about 4.54 decimal TB before those additions. Compare your estimate against the current allowance for the exact Hetzner product and location.
Does a VPS guarantee an uninterrupted YouTube broadcast?
No. The VPS, FFmpeg, source, network connection and YouTube ingest can fail independently. Supervision, monitoring and a tested recovery procedure can help you respond, but they do not guarantee perfect continuity.