To stream prerecorded video from a Hetzner dedicated server to YouTube Live, run an encoder on the server that plays or schedules media and sends it to YouTube’s ingest endpoint using the event URL and stream key. YouTube’s encoder setup works across software encoders, but it does not establish that a particular Hetzner server can sustain uninterrupted 24/7 output.
The practical sequence is to confirm rights and channel access, prepare the files, choose software that can run unattended on your operating system, configure an event and ingest, then test the exact feed and check the server’s current network and product terms. Treat continuous operation as something to validate and monitor, not a property guaranteed by the word “dedicated”.
Prepare media you have rights to stream
Start with the content, not the server. Make an inventory of every video, still image, voice recording and music track you plan to include. For each item, confirm that your permission covers a live broadcast on YouTube, the intended territory, and repeated or continuous use. A licence for an ordinary on-demand upload may not cover a 24-hour live rebroadcast. Keep copies of licences, releases and correspondence somewhere you can reach if a rights question arises.
YouTube’s livestream terms and conditions put responsibility on the content provider to hold the necessary rights for worldwide exploitation of live content, including applicable music rights. Check the wording of your own permissions rather than assuming that a track is usable because it is available in a library or was cleared for another platform. For devotional channels, this can include the recording and arrangement as well as the underlying composition. For local news or small businesses, it can include footage, photographs, logos and guest appearances.
Prepare a known-good set of files in a format your chosen playout software can read. Check that each file opens fully, has the intended audio, and ends cleanly. Where a long playlist is assembled from shorter pieces, watch transitions: black frames, abrupt level changes and audio gaps can be distracting even when the encoder is working correctly. Keep an original copy separate from any versions converted for streaming.
File size is not the same as live bandwidth. A compressed file on disk is read by the encoder, which produces an outbound stream at the configured video and audio bitrate. Converting files to a manageable format may make playout easier, but it does not replace checking the output bitrate or the server’s sustained upload path. If your library contains large MP4 files that stumble in playback, review practical ways to fix OBS media-source stuttering before assuming the network is at fault.
Also decide what the viewer should see and hear when a programme ends or a file is missing. A loop may repeat the same playlist; a schedule may change programme blocks at set times. Neither method creates new material or removes your responsibility to check originality and rights. YouTube’s monetisation policy applies to live streams and evaluates the channel as a whole; repetitive or mass-produced content can affect eligibility. A successful technical broadcast is not evidence that a channel qualifies for monetisation.
Choose a playout and encoder approach
A server-side workflow needs software that can both play the media and encode a live feed. A general encoder such as OBS is among the options in YouTube’s encoder guidance. That tells you the software can be used in a YouTube workflow; it does not answer whether a specific machine, operating system, graphics setup, or hosted-server configuration will run it well unattended.
For a simple loop, the software must be able to read the files, repeat a playlist or scene as required, keep audio and video in sync, and recover in a useful way from a media error. For scheduled programming, it also needs a reliable schedule or a playout system that can switch between sources. Before choosing, check compatibility with the exact operating system available on the server, whether it can be managed remotely, and how you will start it again after a reboot. Some desktop-oriented applications rely on a graphical session; test the actual way you intend to run them instead of assuming a server installation behaves like a home computer.
There are two broad approaches:
| Approach | Useful when | What you must verify |
|---|---|---|
| Encoder with media sources and a playlist | You have a modest library and want to repeat a straightforward sequence | File playback, looping behaviour, audio continuity, unattended startup and recovery |
| Playout or scheduling software feeding an encoder | You need programme blocks, timed changes or more control over a channel schedule | How it hands media to the encoder, schedule behaviour, source transitions and failure handling |
Do not select an encoder only because it has a familiar name. Test whether it can run without someone logged in to click through dialogs, whether the media stays available after a restart, and whether its logs or status indicators help you diagnose a stopped feed. Hardware encoding may reduce the work done by the processor, but availability and configuration depend on the specific server and software; check the exact current specifications and terms rather than inferring capability from a product category.
If you are comparing a dedicated server with a virtual machine, consider the operational tasks you will own in either case: software updates, remote access, storage, playback checks, restarts and bandwidth. A Google Cloud VM workflow for an always-on prerecorded stream offers a useful contrast in the questions to ask, but its instructions and capacity assumptions should not be transferred to a Hetzner product without checking that product separately.
Create or schedule a YouTube Live event
First check that the channel is able to livestream. YouTube’s help material says the channel must be verified and have no live-streaming restrictions in the preceding 90 days; first-time activation can take up to 24 hours. The minimum age to livestream is 16. These are YouTube’s current eligibility conditions as described in its live-streaming help, so check that page before your planned start rather than discovering a restriction during setup.
In YouTube Studio, open the Live Control Room and create a stream. For a channel that needs a predictable start time, schedule the event and enter its title, description, privacy and other details there. Review what the audience will see on the watch page and whether the stream is public, unlisted or private. Scheduling the YouTube event and scheduling the server’s playout are separate jobs: you need both to agree on when the feed begins and what is playing.
YouTube’s encoder flow distinguishes sending a live feed from uploading a video file. The encoder converts the media into a live digital stream and sends it to YouTube. A scheduled event does not itself make the server play your files, and a running encoder does not necessarily mean viewers can see the event you intended. Confirm which event and stream configuration are active in Live Control Room before starting the encoder.
If this is your first time with the channel or software, leave time for a private or unlisted test. A private test can expose a wrong source, muted audio, a poor crop or an incorrect event association without presenting the production feed as finished. Keep in mind that privacy settings and event behaviour are controlled in YouTube Studio; do not use a test event as a substitute for checking the final public event’s settings.
Configure the ingest URL and stream key
The event’s stream URL tells the encoder where to send the feed; its stream key identifies the stream configuration and should be handled like a password. In the encoder, choose YouTube or the corresponding custom server option, enter the URL supplied in Live Control Room, and enter the matching key. Some encoders offer a direct YouTube sign-in workflow; others ask you to paste the values manually. Follow the workflow shown by the software and the event currently selected in Studio.
Keep the key private. Do not put it in a public script, screenshot, shared document or support post. Restrict access to the server account and configuration where the key is stored. If you believe it has been exposed, replace or reset it through YouTube’s controls and update the encoder before going live. The key is not a general password for your Google account, but anyone who obtains it may be able to send a feed to its associated ingest setup.
Start the encoder only after checking the event, source and key together. If the wrong event is selected, a perfectly valid outbound feed can still land somewhere other than the intended scheduled broadcast. Wait for Live Control Room to recognise the incoming stream and inspect the preview. If the preview remains absent, check the URL, key, encoder state and network connection before changing several settings at once.
For ordinary RTMP or RTMPS ingest, YouTube’s current guidance includes H.264 video, constant bitrate (CBR), a keyframe interval of two seconds recommended and no more than four seconds, frame rates up to 60 fps, and AAC or MP3 audio. Use YouTube’s current encoder settings table to choose resolution, frame rate and bitrate together. There is no single bitrate that fits every picture size and frame rate, and the table is a starting point rather than proof that your server’s outbound capacity is adequate.
Use RTMPS when the encoder supports it
For a standard YouTube Live workflow, choose RTMPS when your encoder offers it. It is the encrypted version of RTMP recommended by YouTube for supported use. Some software presents YouTube as a destination and selects the protocol for you; with a custom server field, use the RTMPS ingest address provided in Live Control Room when available. Do not guess a URL by editing an address: copy the current value shown for the event.
RTMPS is usually the straightforward choice for prerecorded loops that use common video and audio formats. HLS is another ingest option, but YouTube describes it for particular cases such as HDR or codecs not supported through RTMP. Its workflow has higher latency and requires specific segment and rolling-playlist behaviour. That extra configuration is not an automatic improvement for a simple playlist, so use HLS only when your encoder and content requirements call for it and the official instructions match your setup.
| Ingest option | Consider it when | Trade-off to account for |
|---|---|---|
| RTMPS | Your encoder supports the usual YouTube workflow and your feed uses compatible settings | Confirm the encoder’s destination and settings, then validate the incoming stream |
| HLS | You need a supported HDR or codec case that RTMP does not serve | More specific segment and playlist requirements, and higher latency |
This is a protocol choice, not a way to make an unsuitable server suitable. Both approaches still require a valid event configuration, supported media and enough sustained outbound capacity. If your encoder cannot use RTMPS, consult its documentation and YouTube’s current supported ingest options rather than assuming that every protocol setting is interchangeable.
Test and monitor the outbound video
Before relying on a continuous feed, run a test using the same encoder, files, resolution, frame rate and bitrate you intend to use. Include a representative portion of the playlist: a static devotional image, a high-motion scene, a section with music, and any transition that could reveal a playback or audio issue. Watch the preview in Live Control Room and open the corresponding watch page with the privacy setting you intend to use.
Check that the video is not cropped unexpectedly, the sound is present and at a steady level, and the image is not visibly breaking up. Compare the encoder’s output status with YouTube’s stream-health indicators. YouTube recommends monitoring stream health and leaving upload headroom; a brief successful preview is not a guarantee that a long-running feed will remain healthy. YouTube also notes that disruptions can break a stream, so decide how you will detect a stopped feed and what you will do next.
Write down a simple response sequence: confirm whether the encoder is running, check its source and output status, inspect Live Control Room, and only then restart or reconfigure. If you use a backup feed, test the handover rather than merely assuming it will take over. A restart may restore output, but viewers can still experience an interruption and YouTube’s event may need attention. The article on why YouTube may end a 24/7 devotional stream automatically is relevant when diagnosing event behaviour, but check the current account and stream status rather than treating any one symptom as a universal cause.
Monitoring should include the media itself, not just a green “connected” indicator. A feed can remain connected while the source is frozen, silent or repeating the wrong item. At intervals you choose, inspect the visible programme and listen to the audio, and check that the scheduled content is still appropriate. If you cannot watch continuously, arrange a realistic alert or check-in process and be clear about what it can and cannot detect.
Check server traffic and operating constraints
Size the connection for the encoded output, not the file’s size on disk. YouTube’s streaming tips recommend leaving about 20% room above the total upload bitrate. If you send more than one output, account for the combined bitrate. That headroom is YouTube’s recommendation, not a promise about a rented server’s sustained capacity.
The relevant measurement is outbound capacity from the selected server and its network path to YouTube, not a speed test from your home connection. A short test may show that a connection can transmit at a particular moment; it does not settle whether it can keep doing so under your chosen workload or within the product’s current traffic conditions. Use the intended encoded settings for a sustained validation run, look for drops or health warnings, and confirm the server’s current network and traffic terms with Hetzner for the exact product and location.
This workflow cannot establish whether a particular Hetzner dedicated server is suitable for uninterrupted 24/7 output. Hardware, encoding support, operating-system access, network conditions and product terms vary, and the current details must be checked directly. Do not rely on a model name, a quoted traffic allowance or an assumed host permission unless it appears in the applicable current Hetzner documentation or contract. The GPU cost questions for a 24/7 stream can help frame whether encoding load matters to your plan, but it does not prove what a particular host configuration can do.
There are operating costs beyond the server rental: your time maintaining the files, updating software, protecting credentials, monitoring output and responding to failures. If the workload is a modest loop and you do not need to administer an operating system, a managed workflow may remove the specific burden of leaving your own computer running and watching a local encoder. StreamNeo turns an uploaded file into a YouTube live stream, so that particular always-on computer and encoder task is not yours to manage; it is YouTube-only, and it does not settle content rights, event eligibility or your channel’s monitoring needs.
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 stream a video file directly from a Hetzner server to YouTube?
The server does not normally upload the file as though it were a standard video upload. An encoder reads the file, packages it as a live feed and sends that feed to YouTube using the event’s ingest URL and stream key. You still need to test the media source, encoder and outbound connection together.
Can I run OBS on a dedicated server?
OBS is listed by YouTube as a software encoder option, but that does not confirm that it will suit every server or operating-system setup. Check compatibility and test how it behaves when run remotely and unattended, including what happens after a reboot or media error. Do not treat a successful desktop installation as proof of continuous operation.
What bitrate should I use?
Choose a bitrate from YouTube’s current settings guidance for the resolution and frame rate you plan to send, then test that exact output. Leave the recommended upload headroom and check sustained outbound capacity from the selected server. A bitrate that works on one server or network path may not work on another.
Can prerecorded live streams be monetised?
A technically working live stream does not establish monetisation eligibility. YouTube’s policy considers originality, reused material and the channel as a whole, including repetitive or mass-produced content. Review the current policy and confirm that you have the necessary rights for the content you broadcast.