A Hetzner VPS can run FFmpeg as a YouTube live encoder while your own computer is switched off. The workflow is to create a server with a public IP, install an FFmpeg build that supports your chosen encoding path, and send the output to YouTube over RTMPS.
The important choice is whether to copy an already compatible audio/video stream or transcode it into the output format you need. Copying can use less CPU, but it is only suitable when the input codecs and stream properties fit the YouTube output you intend to send; transcoding gives you control at the cost of processing demand.
Create a Hetzner Cloud server and connect over SSH
In Hetzner Cloud Console, create a Cloud server, select a location, an operating system image such as Ubuntu, and a server type. The server needs a public Primary IP to have a public network interface. Hetzner describes Cloud servers as virtual machines, but its available types, pricing and included allowances can change. Check the current console before creating one rather than choosing from an old price comparison.
A server’s suitability depends on the workload. A job that copies compatible streams does not have the same CPU needs as one that decodes and re-encodes video. Codec, resolution, frame rate and any additional processing all matter. No server type can be named as a safe choice without knowing those details and observing the actual load. If you are uncertain, test with your real source and watch CPU use, stream health and network throughput before making the channel depend on it overnight.
Add an SSH public key during provisioning where practical. Connect from a terminal using the public IP and the account provided by your selected image, for example ssh user@SERVER_IP. The account name can vary by image. If you use a Cloud Firewall, set rules deliberately: Hetzner says unspecified inbound traffic is blocked by default, while outbound traffic is permitted by default when no outbound rules have been configured. Keep SSH access open from a trusted address before changing firewall rules, or you can lock yourself out. The Hetzner Cloud Firewall documentation describes its default behaviour.
YouTube ingest is an outbound connection from the VPS, so a firewall policy must allow the server to reach the selected ingest destination. Avoid opening inbound ports “for streaming” unless your design specifically requires them; for this workflow, FFmpeg initiates the connection to YouTube. Before settling on a plan, also account for continuing charges. Hetzner states that servers are billed while they exist, including when powered off, and that server plan prices exclude public IPs. It also bills outgoing traffic. Verify current server, IP and traffic rates on Hetzner’s site or in the console before provisioning.
Install FFmpeg and check the build
On Ubuntu, you can install the distribution’s FFmpeg package with sudo apt update followed by sudo apt install ffmpeg. Package contents depend on the distribution and build options, so do not assume that every package includes the encoder you need. Check the version and available encoders:
ffmpeg -version
ffmpeg -encoders
Look for libx264 if your planned command uses H.264 encoding, and check the relevant audio encoder if you intend to transcode audio. A stream-copy command may not need an encoder for the copied tracks, but FFmpeg still needs the right input and output protocol support. The installed build must support RTMPS for the intended encrypted ingest path. If a required encoder or protocol is absent, choose a suitable package or build before you rely on that command; an example from another system may not work unchanged.
Keep the machine’s packages maintained and restrict administrative access. Do not expose SSH broadly just because the server is cloud-hosted. For an unattended channel, operational basics matter as much as the first successful command: know how to connect, where logs go, how to stop a process, and how to recover access if a change goes wrong.
Prepare the source: copy or transcode
Put the media on the VPS or make it reachable from there, then inspect its streams before choosing a command. ffprobe can report the codecs, frame rate, dimensions, duration and audio/video stream layout. Confirm that the source actually has the audio and video you expect. A file that plays correctly on your laptop may still have a codec or stream layout that does not fit your planned live output.
Use stream copy only when the existing encoded tracks are compatible with the intended YouTube output and the container/muxing path FFmpeg will use. Copying avoids decoding and re-encoding those tracks, which can reduce CPU demand and preserve the source encoding. It does not let you change the video codec, resolution or bitrate: those properties are already present in the encoded stream. If the source is incompatible, or you need to set a different output profile, transcode instead.
A transcode decodes the source and encodes it again. That gives you control over codec, frame rate, resolution and bitrate, but requires more CPU and may introduce quality loss depending on settings. Do not infer that a VPS can handle a particular transcode because it has worked on another machine. Run the actual source for long enough to observe CPU use and whether FFmpeg can keep pace in real time. A file with a demanding codec or high resolution can behave differently from a short, simple sample.
If your channel alternates clips, also test what happens at file boundaries. A playlist or concatenation method must account for compatible stream properties and transitions; otherwise you may see a pause, a black screen or a failed process when one item ends. For a 24/7 nature loop, the practical checks in this guide to avoiding a black screen between videos are relevant alongside the encoder test. Do not leave the source loop untested just because the first clip streamed correctly.
Get the YouTube Live URL and protect the key
Create or schedule the live event in YouTube Live Control Room. Copy the stream URL and stream key from its streaming settings; the exact ingest address can vary, so use the one shown for your event rather than copying a URL from an unrelated tutorial. Choose RTMPS when it is available. YouTube describes RTMPS as RTMP secured with TLS/SSL and recommends it for YouTube Live in its RTMPS guidance.
Treat the stream key like a password. Anyone who obtains it may be able to send a signal to your broadcast. Do not paste it into a public repository, share it in screenshots, or include it in a public support post. A command typed directly into a shell can be saved in shell history, and a key embedded in a script can be exposed to anyone who can read that file. Use a private configuration or environment mechanism with appropriately restricted permissions, and avoid printing secrets into logs. The practical choices for handling this credential are covered in how to secure a YouTube stream key in an FFmpeg VPS script.
When you set or rotate the key in Live Control Room, update the configuration used by the VPS as well. Keep a record of which event and key the process is using, without storing the secret in an exposed place. If the stream does not connect, first compare the destination and key with the current event settings; do not assume an old key remains valid after changes.
Choose output settings for the source and connection
YouTube’s encoder guidance lists RTMP/RTMPS ingest and supports H.264, H.265/HEVC and AV1, with up to 60 frames per second. It recommends constant bitrate (CBR) and a two-second keyframe interval, and says not to exceed four seconds. For H.264, its recommended bitrate table includes 10 Mbps for 1080p30 and 12 Mbps for 1080p60. These are YouTube recommendations for encoder output, not measurements of a Hetzner connection or promises that a particular server can sustain the job. Consult the current YouTube Live encoder settings and choose a quality your source and available outbound connection can reliably support.
The settings must agree with one another. A two-second GOP at 30 fps corresponds to 60 frames, so -g 60 is an example for that frame rate; at another frame rate, choose a GOP length that still represents the intended interval. A bitrate parameter does not make a weak connection stronger. Leave headroom for variation in the connection and do not select a profile solely because it offers a sharper image on paper. Test the actual VPS route and monitor YouTube’s stream health.
| Choice | What it changes | Main trade-off |
|---|---|---|
| Stream copy | Sends compatible encoded tracks without re-encoding | Lower processing demand, but no control to repair incompatible codec or output properties |
| Transcode to H.264 | Encodes video to a selected output profile | More control over output, with higher CPU demand and possible quality loss |
| 1080p30 H.264 | YouTube’s recommended bitrate entry is 10 Mbps | Lower frame rate than 60 fps; still needs a dependable connection and suitable source |
| 1080p60 H.264 | YouTube’s recommended bitrate entry is 12 Mbps | More motion detail where the source supports it, with greater bitrate and processing demands |
The table’s figures are YouTube’s published recommendations, not universal requirements. The H.264 and AAC settings accepted by YouTube Live provide another reference point for considering format compatibility, but your source and current YouTube settings remain decisive. If your source is already encoded to an appropriate profile, avoid transcoding merely to make the command look more complete.
Send the stream over RTMPS
For a file input, -re paces reading in real time rather than sending the file as fast as storage can provide it. This illustrative command transcodes video to H.264 and audio to AAC, then sends an FLV stream to the RTMPS destination. Replace the path and destination placeholders with your own values; never put a real key into a published script.
ffmpeg -re -i /path/to/input.mp4 \\
-c:v libx264 -preset veryfast -b:v 6000k -maxrate 6000k -bufsize 12000k \\
-g 60 -c:a aac -b:a 128k \\
-f flv 'rtmps://INGEST_HOST/APP/STREAM_KEY'
This is a command shape, not a tested universal profile. Its bitrate is an example and should not be treated as the right setting for every source or resolution. At 30 fps, -g 60 requests a two-second GOP; change it when the output frame rate differs. The precise URL form comes from Live Control Room. FFmpeg’s protocol documentation covers RTMP-family protocols, including RTMPS; support depends on how FFmpeg was built.
For a compatible pre-encoded input, the command can use -c copy instead of video and audio encoders, but only after you have checked that the streams are suitable for the output. For example, a file with an incompatible video codec cannot be made into H.264 merely by copying it. If the connection fails during setup, check that the build supports RTMPS, the destination is the current YouTube URL, the key is correct, and outbound access is allowed. FFmpeg output should be kept available for diagnosis, but redact credentials before sharing logs.
A successful first start does not prove a 24/7 process will recover well after a network interruption, source end, reboot or key change. Once the command has passed a real test, you can make it persistent with a service manager such as systemd and add a deliberate restart policy. Configure logging and log rotation, and test the recovery behaviour rather than assuming a restart will always restore the correct live event. If managing Linux, the FFmpeg process, access controls and recovery is not work you want to own, StreamNeo removes the specific burden of keeping your own computer and VPS process running for a file-based YouTube broadcast.
Test in Live Control Room and troubleshoot
Start with a short controlled test while you can observe both FFmpeg’s terminal output and YouTube Live Control Room. Check that the preview appears, that audio is present and at a sensible level, and that motion and transitions look right. Review YouTube’s stream health messages rather than treating a running FFmpeg process as proof of a good broadcast. Confirm that the event is receiving the stream you meant to send, not simply that some signal reached YouTube.
If the preview is absent, verify the stream URL and key against the event, the RTMPS support in your FFmpeg build, and the server’s outbound connectivity. If video appears but audio does not, inspect the source’s audio stream and the selected audio mapping or encoder. If YouTube reports instability, compare the output bitrate with the connection you observed, then test a lower-quality profile before returning to a higher one. If FFmpeg reports that an encoder is unavailable, confirm the package’s encoder list instead of repeatedly changing unrelated command flags.
Watch CPU use during a transcode and check whether the output is being produced in real time. A process that falls behind under sustained load may look fine during a brief test. With stream copy, CPU may be less demanding, but you still need to check network stability, source continuity and YouTube’s health indicators. Record the working command shape and non-secret settings so that a future restart is repeatable, while keeping the key in a protected configuration.
Before leaving the channel unattended, test the exact lifecycle you plan to use: starting the process, stopping it, recovering after a deliberate interruption, and confirming the right event reconnects. A service restart policy can restart a process, but it cannot correct a wrong key or incompatible source. Size the VPS from observed behaviour rather than a claimed capacity, and revisit costs as you change the server, public IP or outgoing transfer needs. A smaller profile may be the sound choice if it gives you a stable picture and audio with less pressure on the connection.
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 stream copy for any MP4 file?
No. MP4 is a container, not a guarantee that the encoded video and audio are compatible with your intended YouTube output. Inspect the streams first; transcode if the codecs or output properties need to change.
Which Hetzner server size should I choose?
There is no single size that can be recommended without the source codec, resolution, frame rate and whether you copy or transcode. Start with a test configuration you can afford, observe CPU and network behaviour with the actual media, and adjust based on what you see. Verify current server, IP and traffic charges before creating the VM.
Does the RTMPS URL stay the same for every broadcast?
Use the URL and key currently shown in Live Control Room for the event you are sending to. Do not rely on a saved example from another channel or event, and protect the key as a credential.
Will systemd guarantee the stream stays live?
No. A service manager can restart a process under configured conditions, but it cannot guarantee a working source, valid credentials, network availability or YouTube acceptance. Test the restart path and monitor the broadcast after changes before leaving it unattended.