To run an FFmpeg stream from a Hetzner Cloud VPS to YouTube Live, provision a server with a public route to the internet, prepare your media and FFmpeg settings, then send the output to YouTube’s supplied ingest URL using the event’s stream key. The right server and settings depend on what you are encoding; this guide includes no tested command, benchmark, or guarantee that a particular server will encode your stream in real time.
The practical sequence is to create or select a YouTube Live event, configure FFmpeg for the actual input and output, protect the stream key, and verify the result in YouTube Studio. Treat the first run as a test, not as proof that the same configuration will handle a different source, resolution, frame rate, or continuous schedule.
Choose a Hetzner Cloud server for the workload
Start with the work the server must do, rather than a plan name. Relaying an already encoded feed is different from decoding and re-encoding a high-resolution video. A static devotional image with audio, a moving lofi visual, and a camera feed impose different demands on the input handling and encoder. The codec, resolution, frame rate and FFmpeg encoder preset also affect CPU use.
Hetzner describes Cloud servers as virtual machines and distinguishes shared and dedicated resource classes. Shared resources may suit a workload whose demands are modest and whose tests show adequate capacity. Dedicated resources are worth considering when you need more predictable CPU availability, but the research behind this guide establishes no plan winner or universally sufficient server. Compare the resource model and cost against your actual encoding requirement, then measure the workload on the server you intend to use.
A public route matters as well as CPU. Hetzner’s overview identifies a public Primary IP as a way to establish internet connectivity for a public-network server. A private-only arrangement needs some other route to YouTube and is outside the simple workflow described here. Check the Hetzner Cloud overview for current product details before provisioning; do not infer from a product label alone that it will meet your stream’s requirements.
The traffic is outbound from the VPS to YouTube. Hetzner’s Cloud API documentation explains that a firewall with no inbound rules drops inbound traffic, while no outbound rule means outbound traffic is accepted. That provider firewall is separate from a firewall configured inside the guest operating system. Check both, allow only the outbound path and ports your setup needs, and retain only the inbound administration access you actually use. Do not expose an administration service broadly just to make the stream work.
If you are deciding between a VPS workflow and another way to keep a recorded programme online, the practical considerations in running a recorded sermon stream from a VPS may help frame the operating burden. A VPS gives you control over the operating system and FFmpeg process, but you also own configuration, updates, monitoring and recovery.
Prepare the operating system and input
Choose a supported operating system you can maintain and that has a suitable FFmpeg package or build. This article does not prescribe a distribution-specific installation command: package names and available FFmpeg features vary by operating system and repository. Confirm the current installation instructions for your chosen OS, and check that the resulting build includes the encoders and protocols you plan to use.
Before starting FFmpeg, inspect the source file or live input. Establish its video dimensions, frame rate, audio presence, codecs and duration where relevant. A file that already has compatible codecs may be relayed or remuxed rather than re-encoded, depending on the workflow. If you change codecs, resolution or frame rate, FFmpeg must do additional work. A source with silent audio, variable frame rate or an unusual pixel format can also behave differently from a straightforward test clip.
For a file-based channel, keep the media in a stable location accessible to the account running FFmpeg. Check available disk space and confirm that the file can be read without an interactive desktop session. For a camera or other live input, separately verify that the VPS can actually access it; a camera attached to your home computer is not automatically available to a remote virtual machine. This distinction often changes the design from encoding on the VPS to sending an already encoded feed from the capture machine.
Plan how the process will run when you disconnect from an SSH session. A manually started process may stop if its session ends, and a host reboot or FFmpeg error can interrupt a broadcast. A system service or supervisor can be part of a robust setup, but service definitions, restart policies and secret-file permissions depend on the exact operating system and command. The research for this guide has not validated a particular systemd unit or recovery configuration. Test the chosen process manager, including what happens after a deliberate stop and a reboot, before relying on it overnight.
Install and configure FFmpeg for the actual media
FFmpeg is both a media reader and an encoder. Identify whether you need to transcode video, audio, both, or neither. If you encode unnecessarily, you spend CPU and may reduce reliability without improving the programme. If you simply pass through a codec or format YouTube will not accept for that ingest, the stream can fail or show an error. Match the output to YouTube’s current encoder guidance and to the capabilities of the source.
YouTube’s live encoder settings support RTMP and RTMPS ingest and list H.264, H.265/HEVC and AV1 video, with AAC or MP3 audio. They also specify constant-bitrate encoding, up to 60 frames per second, and a recommended keyframe frequency of two seconds, not exceeding four seconds. A conservative interoperability starting point for many beginners is H.264 video with AAC audio, but this is an example, not the only supported combination. Verify the current official settings page for the target event and format.
Use the source’s intended output shape rather than choosing a large frame size by habit. For example, a 720p source does not gain useful detail merely because it is upscaled to 1080p, while encoding at a higher frame rate than the source can consume CPU without adding genuine motion information. A camera programme with fast movement may justify a higher target than a static graphic, but the server still has to produce that output at the required rate. Keep audio sample rate and channel layout compatible with the input and output, and listen to the test for clipping, missing channels and accidental silence.
YouTube’s published recommended H.264 bitrate figures provide a starting reference, not a promise that a particular VPS uplink or encoder can sustain the stream. Use the official table for any other resolution or frame rate rather than extrapolating from the entries below.
| Output target | YouTube recommended H.264 video bitrate |
|---|---|
| 720p at 30 fps | 6 Mbps |
| 1080p at 30 fps | 10 Mbps |
| 720p at 60 fps | 8 Mbps |
| 1080p at 60 fps | 17 Mbps |
These figures are for video; audio and transport add traffic. Leave room above the selected outgoing bitrate for variation and overhead, and check the VPS’s actual outbound capacity while encoding. A nominal port speed is not evidence that your complete path will hold a constant stream rate. If you lower the bitrate, resolution or frame rate to fit the real workload, make that change deliberately and verify the resulting picture and sound.
If the programme is a playlist or a repeated recorded file, the input and process-lifetime decisions matter as much as the encoder flags. The VLC-based guide to a 24/7 Telugu old-songs channel covers a different software path, but its channel-planning context can help you decide whether a single file loop, a playlist, or a live source is the right input. Do not copy a command or assume the two applications share the same options.
Create or select a YouTube Live stream
In YouTube Studio, create a live stream or open the event you intend to use. Confirm the event’s visibility, title, schedule and other settings before sending video. In the Live Control Room, YouTube provides the stream URL and stream key associated with the destination. Use the endpoint and key shown for that stream rather than guessing a URL from a tutorial.
The stream key is a credential. YouTube describes keys as “like your YouTube stream’s password and address.” Anyone who obtains it may be able to send a feed to that destination, so do not paste it into a public issue, chat, screenshot or shared document. If it is exposed, reset it in YouTube Studio and update the sending configuration. Read YouTube’s instructions for creating a live stream when the Studio layout or workflow differs from what you see.
Think about whether you need a scheduled event or a stream that is ready to start when FFmpeg connects. The Studio state and the broadcast process are related but not identical: a healthy encoder connection does not, by itself, mean that the public-facing live event is configured as you intended. Check the preview and event status before you share a viewing link or start a planned programme.
Pass the ingestion URL and key securely
YouTube recommends RTMPS, which carries RTMP over SSL. Its documentation specifies the rtmps scheme and port 443 for a valid YouTube endpoint. Prefer the RTMPS endpoint presented for the event when available, and follow YouTube’s supplied URL format. Do not substitute an endpoint from an old tutorial if Studio gives you a different one.
FFmpeg’s output configuration needs the event’s ingest destination and the key in the format YouTube specifies. Avoid publishing a filled-in output URL, because the key may be embedded in that URL. This guide deliberately does not include a copy-and-paste command: the correct input options vary widely between a local file, capture device and remote feed, and a complete command also depends on the installed FFmpeg build and chosen encoders. A partly applicable command can silently select the wrong stream or expose a credential.
For a first private test, enter the credential in a way that does not leave it in shell history, a public script, or logs visible to other users. A protected configuration file or environment-specific secret handling can reduce accidental exposure, but the right approach depends on who can read the account and how the process manager starts. Verify the permissions and logging behaviour yourself on the selected operating system. Do not assume that hiding a key in a script makes it secure if that script is shared or backed up in a readable location.
YouTube’s RTMPS guidance explains the secure endpoint approach. Test the connection with the key kept private, and rotate it in Studio if you believe it has been revealed. For a longer-running channel, document where the authorised operator can update the secret without putting it into routine troubleshooting notes.
Start the process and verify YouTube stream health
Start with a controlled test, not the real overnight schedule. Watch FFmpeg’s output for input detection, encoder initialisation, frame progress and connection errors. An initial connection message is not enough: leave the test running long enough to see whether frames continue to arrive and whether the chosen output rate remains stable. If FFmpeg exits, preserve the useful error text privately, but remove any stream key before sharing logs for help.
Open YouTube Studio’s Live Control Room and check the preview, stream health indicators, audio and event status. Confirm that the picture has the intended dimensions and motion, that the audio is present and in sync, and that there are no persistent warnings about bitrate or dropped frames. A successful FFmpeg process can still send the wrong audio track, a blank image or a stream that Studio cannot present as expected.
If you are running a 24/7 loop, plan for detection as well as startup. The guide to monitoring a YouTube loop when nobody is watching is relevant because a quiet dashboard does not prove that a video and audio feed are still reaching viewers. Decide who receives an alert, what state they should check in Studio, and how they can restart or stop the process without exposing the key.
A restart policy is not a substitute for diagnosing repeated failures. If a service restarts FFmpeg indefinitely, it can obscure a bad input path, rejected key, full disk or incompatible setting. Record the expected process state, test recovery from an ordinary interruption, and check whether a host reboot requires an operator action. The exact service configuration has to be validated on your operating system and FFmpeg version; no unit file or restart behaviour has been tested for this article.
Test encoding capacity before relying on it
YouTube recommends testing ahead of the event with audio and movement similar to the intended programme, monitoring stream health and checking outbound capacity against the selected bitrate. A still picture and silence are a weak test for a moving camera or a music channel. Use representative material, including the busiest or most demanding part of the programme, and let the test run long enough to spot recurring stalls or resource pressure.
Watch CPU use, memory, network traffic and FFmpeg’s progress while the stream is live. The point is not to chase a universal threshold, but to learn whether the selected server keeps pace with the input and output you actually plan to use. If frames are not being encoded as quickly as the source requires, lower the encoding workload, change the encoder settings, or choose a server with a different resource profile and test again. If outbound traffic is unstable, reduce the target bitrate or investigate the route before scheduling a broadcast.
Repeat the test after material changes: a new FFmpeg build, a different encoder preset, a higher frame rate, a new source file or an operating system update can alter behaviour. Keep notes on the exact OS, FFmpeg build, input characteristics and chosen settings so you can reproduce a working configuration. These notes are more useful than claiming that a server model is suitable in general, because the research provides neither a tested command nor a benchmark for any Hetzner machine.
If the operational burden of maintaining a VPS process is not the point of your channel, consider whether a file-based workflow would suit you better. StreamNeo removes the need to keep your own computer on for a file-based YouTube stream: you upload a video, provide the YouTube stream key, and the broadcast runs with monitoring and automatic restart if it drops. It is YouTube-only, and it does not replace this VPS workflow when you need to control a live source or customise FFmpeg on your own server.
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 any Hetzner Cloud server for YouTube Live?
No single server choice can be recommended for every input and encoding target. CPU demand depends on what FFmpeg reads and encodes, while the outgoing stream also needs a working internet route and enough capacity for the selected bitrate. Test the exact workload on the machine you plan to use.
Should I use RTMP or RTMPS?
Use the YouTube-provided RTMPS endpoint when it is available for your event. YouTube recommends RTMPS and documents it as RTMP carried over SSL, using the rtmps scheme and port 443. Always use the endpoint and key shown in Studio rather than guessing.
Can I copy a command from this guide?
No. This guide intentionally supplies no tested command, because the input, operating system, FFmpeg build and encoding choices change the correct configuration. Build and validate the command for your actual source, protect the key, and test the resulting feed in YouTube Studio before relying on it.
How do I know the VPS can handle the stream overnight?
Run a representative pre-event test with the same media, motion, audio, resolution and frame rate you intend to use. Watch FFmpeg progress, server resource use, outbound capacity and YouTube stream health; then test recovery from an interruption. No short test guarantees that a later broadcast will stay uninterrupted, so keep a monitoring and response plan.