A continuous YouTube stream from a Hetzner VPS needs more than an FFmpeg command: you need media the server can read, a real-time encoder feed to YouTube, and checks that reveal when any part fails. You manage the server and recovery yourself; neither YouTube nor Hetzner promises uninterrupted uptime.
The basic path is media on or accessible to the VPS, FFmpeg producing a paced live output, and YouTube ingest receiving it over RTMPS. You then supervise the encoder and watch both YouTube’s stream-health status and the server’s resource and network use.
Plan the architecture before creating the server
Draw the path from the source file to the viewer. Your media may sit on the VPS disk or somewhere the VPS can reliably access; FFmpeg reads it and encodes or repackages it in real time; the resulting feed travels out over the server’s network connection to the ingest URL attached to a YouTube broadcast. YouTube then processes that input for the live channel. Each boundary has a separate failure mode: missing or unreadable media, an exited encoder, a blocked or unstable outbound connection, or an ingest problem visible in YouTube’s control room.
Choose first whether to transcode or copy compatible media. Transcoding can standardise resolution, frame rate, codec and audio, but it consumes CPU continuously. Copying compatible streams reduces that work, but leaves you less control over the source’s encoding characteristics and still requires testing with your specific file and FFmpeg build. Do not assume that a file which plays locally will make a suitable continuous live input unchanged.
For a single modest channel, a Cloud VPS may be sufficient if its sustained CPU and outbound connection suit the chosen output. A stream-copy workflow can have a different compute profile from an encode at 1080p. If predictable CPU capacity matters because you are transcoding continuously, compare shared-resource and dedicated-resource choices and test the actual workload rather than relying on a plan label. The practical distinctions between server hosting approaches are covered in live-streaming server hosting basics.
Make the operating choice explicit too. Self-managed FFmpeg gives you control over files, playlists and settings, but you own process supervision, secret handling, log checks and recovery testing. A managed continuous-stream service can remove some recurring server administration, which may suit a non-technical operator; it is less suitable if you need to manage the whole encoder environment directly. Whichever route you choose, decide who notices an interruption and what they will do about it.
Prepare media the VPS can read
Keep the media on the server’s filesystem if it is a fixed loop and fits comfortably within available disk space. That avoids making every playback cycle depend on a remote mount or a separate file service. If you update content often, a remote source or a deployment process may be more convenient, but build in a way to verify that the newest file arrived intact before switching the live process to it.
Use descriptive file names and stable paths. A playlist that refers to /srv/channel/current.mp4 is easier to maintain than one tied to an administrator’s home directory. Set ownership so the dedicated account running FFmpeg can read the source without being able to alter unrelated system files. Check available disk space before copying large media, and avoid deleting the active input during a playlist update.
A continuous loop can make a short source repetitive. For a devotional music channel, for example, one long programme or a planned sequence may feel more deliberate than a single short clip replaying without context. If you use a playlist, decide how it should progress and what should happen when a file is missing. Test the transition behaviour while the stream is private or otherwise not being promoted to viewers. The FFmpeg workflow for a Tamil Carnatic music channel is a relevant companion when the content is a music-led loop.
Check that you have the necessary rights to broadcast the video, music, artwork and other material. A file being technically playable does not settle its rights or whether the planned channel format fits YouTube’s current policies. Review the official policy and eligibility guidance for your content rather than treating VPS configuration as an answer to those questions.
Configure FFmpeg for real-time playback
For a file-based stream, -re tells FFmpeg to read input at its native rate instead of sending the entire file as quickly as possible. A loop option can repeat the input, but looping does not itself restart FFmpeg after an error or reconnect a failed broadcast reliably. Those are separate operational tasks.
A simplified example of the pattern is:
ffmpeg -re -stream_loop -1 -i /srv/channel/video.mp4 \
-c:v libx264 -preset veryfast -b:v 4M -maxrate 4M -bufsize 8M \
-r 30 -g 60 -c:a aac -b:a 128k \
-f flv 'rtmps://INGEST_HOST/APP/STREAM_KEY'
This is an illustrative starting point, not a command verified for every source, FFmpeg build or YouTube account. It uses a 30 fps output and a 60-frame GOP, which corresponds to a two-second keyframe interval at that frame rate. Its 4 Mbps video setting aligns with YouTube’s current H.264 guidance for 240p–720p30; it is not an all-purpose bitrate. For 1080p30, YouTube’s current recommended H.264 figure is 10 Mbps. Check the YouTube encoder settings guidance and choose settings that fit both your content and your sustained outbound capacity.
YouTube recommends constant bitrate (CBR) and a two-second keyframe interval, with four seconds as the maximum recommended interval. In FFmpeg, settings such as -b:v, -maxrate and -bufsize need to be considered together for the selected encoder and source; confirm the actual output rather than assuming that a configuration line guarantees a particular stream. The practical implications of the interval are discussed in YouTube’s RTMP keyframe interval requirements.
The example encodes H.264 with AAC audio and wraps the output in FLV for the ingest connection. A different source or codec may call for different settings. If the source is already suitable, a copy workflow may reduce CPU load, but it should not be treated as a shortcut around checking codec, resolution, frame rate, audio and keyframe behaviour. Look at FFmpeg’s startup output and logs to confirm that it reads the file and produces the expected stream parameters.
Use the right YouTube broadcast and keep the key private
Create the intended live broadcast in YouTube Live Control Room, or configure it through YouTube’s Live Streaming API if you have a reason to automate broadcast creation. Obtain the ingest URL and stream key associated with that broadcast. The URL identifies where the encoder sends data; the stream key is the publishing credential that connects that incoming feed to your channel’s stream.
Treat the key as a password. Do not put it in a script committed to source control, paste it into a public support post, or include it in logs you share. Store it in a file readable only by the account that needs it, or use another appropriate secret-handling method. If it is exposed, regenerate it in YouTube and update the encoder configuration. YouTube describes the connection and key in its live encoder setup instructions.
In the command example, replace the placeholders with the exact ingest host, application path and key shown for the broadcast. Avoid placing the key directly in a command you type interactively, where it may be retained in shell history. Restrict SSH access to the server, apply security updates, and run the encoder as a dedicated unprivileged user rather than as root.
Start with the broadcast set up for testing, then check YouTube’s preview and stream-health diagnostics before making it public. Confirm that the intended video and audio arrive, that the broadcast is attached to the right channel and that the stream is not silently feeding a different scheduled event. A healthy FFmpeg process only establishes that the local program is running; YouTube’s receiving-side status tells you whether its ingest is seeing a usable signal.
Deliver the encoder feed over RTMPS
YouTube supports RTMP and RTMPS ingest and recommends RTMPS, the secure extension to RTMP. Use the RTMPS URL supplied for your broadcast where available. It protects the encoder-to-ingest connection in transit, but it does not make the stream key safe to disclose or establish rights to the media you send.
The VPS must be able to make outbound connections to the selected ingest endpoint. Check that the Hetzner Cloud Firewall and any host firewall rules allow the required egress. A server with a public address is not useful for publishing if its outgoing policy blocks the connection. If FFmpeg cannot connect, inspect its error output, firewall rules, DNS resolution and the exact endpoint before changing video settings.
Bitrate is a sustained outbound load, not merely a quality setting. YouTube’s figures are recommendations for particular codec, resolution and frame-rate combinations; your actual file and output profile need to match the selected guidance. A 1080p30 H.264 stream at the recommended 10 Mbps sends substantially more data than a 720p30 stream at 4 Mbps. Check the current YouTube table rather than lifting a value from an unrelated example.
Hetzner’s included outbound traffic varies by Cloud product and region. Its current traffic terms list 20 TB monthly for the specified EU CX, CPX and CAX Cloud Server categories, while other locations and plans differ; excess traffic is charged in 100 MB blocks. These figures are listed on Hetzner’s site in September 2026, so confirm the allowance and overage terms for your exact plan and location before committing. The source is Hetzner’s Cloud server traffic information.
Estimate usage by multiplying the chosen output bitrate by broadcast hours, then allow for audio, protocol overhead, retries, updates and other server traffic. As a rough arithmetic example, a continuous 1 Mbps stream over 30 days is about 324 GB in decimal units before overhead. Compare that estimate with the current allowance rather than treating it as a bill prediction. Also distinguish a monthly allowance from a speed claim: Hetzner says Cloud bandwidth is not guaranteed and describes about 300–500 Mbit/s as what customers can expect, with instances sharing a host connection. That is not an individual instance guarantee; Hetzner’s Cloud technical FAQ explains the qualification.
Supervise the process and recover failures
FFmpeg does not provide end-to-end supervision simply because it is running in a terminal or launched by a startup script. Run it under a process supervisor such as systemd, with restart-on-failure behaviour and logs that persist long enough for you to understand an interruption. Use a dedicated service account and a configuration file with restricted permissions. Make sure the service starts only after its media is available, and document how to stop it deliberately without triggering an unwanted restart loop.
A supervisor can restart a process that exits, but it cannot decide whether the source file is wrong, the key has been revoked, YouTube is rejecting the feed or a network problem is recurring. Restart policies need to be tested with the chosen input and server. Avoid rapid repeated restarts that obscure the original failure or generate a stream of useless logs; inspect the reason for exit and decide whether the fault needs intervention.
Plan for at least three recovery cases. First, make sure a missing or damaged media file produces an alert rather than an unnoticed blank or stalled channel. Second, test what happens when FFmpeg exits and whether the supervisor brings it back in a way YouTube accepts. Third, reboot the VPS during a controlled test and confirm that the service, media access and credentials are all available afterwards. Do not wait for a real overnight interruption to discover that a unit file points to a temporary path.
Keep an operational note with the service name, media path, log location, broadcast identity and steps to rotate the key. A second person who can follow those notes is useful if the usual operator is unavailable. If a restart does not restore ingest, check YouTube’s current health status and the encoder logs before restarting repeatedly. A cloud-encoder workflow for prerecorded YouTube Live offers a useful point of comparison for readers who want fewer VPS administration tasks. StreamNeo addresses the specific burden of keeping an encoder process alive on your own computer by running an uploaded file as a YouTube stream while that computer is off, but it is YouTube-only and does not replace checking your content or channel requirements.
Monitor stream health, server load and egress
Monitor both ends of the connection. On the VPS, check that the service is active, recent logs show ongoing input and output, the media remains readable, and CPU, memory, disk and network use remain within the capacity you planned for. A process can be active while making no useful progress, so include a receiving-side check in YouTube Live Control Room. Look for the incoming preview and stream-health diagnostics rather than treating a green process status as proof of a healthy public broadcast.
Track outbound use over time and compare it with your estimate. A stream that is stable in a short test may still use more monthly traffic than expected once audio, overhead, retries and other server tasks are included. Watch the chosen server’s actual network behaviour under the intended workload; Hetzner’s shared-host expectation is not a per-instance service guarantee. If viewers report buffering while your own preview looks normal, separate ingest health from viewer playback and investigate each side; see why a 24/7 stream can buffer for viewers.
Set a check schedule that fits the cost of an unnoticed interruption. An unattended devotional channel might need someone to review the dashboard each morning and an alert for a stopped service; a news loop may need a faster response when its output is stale. Keep the alert actionable: identify whether the process stopped, the input disappeared, the server is under pressure or YouTube reports an ingest problem. Avoid exposing the stream key in alert messages.
Before relying on the setup, test the complete path for long enough to exercise the actual source and output settings. Confirm that the loop behaves as expected, audio remains present, YouTube reports healthy input, and a deliberate service restart recovers. Then test a server reboot and verify that the required files, permissions and network rules survive it. These checks reduce avoidable surprises; they do not guarantee that every future network or platform interruption will recover automatically.
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 run a continuous YouTube stream with only FFmpeg?
FFmpeg can read and send media, but a foreground process alone does not supervise itself, alert you to a failed input or verify YouTube is receiving a healthy stream. Use a supervisor, retain logs and check the receiving-side diagnostics. Test restart and reboot recovery with your actual source.
Which bitrate should I use for a Hetzner VPS?
Choose according to the output resolution, frame rate and codec, then check whether the server can sustain that outbound load and whether its regional traffic allowance fits your plan. YouTube’s current H.264 guidance is 4 Mbps for 240p–720p30 and 10 Mbps for 1080p30. Those are recommendations, not a guarantee of stability for your source or VPS.
Does Hetzner guarantee enough bandwidth for a 24/7 broadcast?
No. Hetzner says Cloud bandwidth is not guaranteed and its stated expected networking is not an individual instance guarantee. Check the current terms for your plan, estimate outbound traffic and test the actual server under the intended workload.
Is RTMPS enough to keep my YouTube stream secure?
RTMPS protects the encoder-to-ingest connection in transit, while the stream key remains a secret publishing credential that must be stored and shared carefully. It does not determine whether you have rights to the content or whether your broadcast meets YouTube’s current rules. Check the relevant official guidance for your channel and material.