Uploading videos to Hetzner puts files within reach of your streaming setup; it does not start a YouTube broadcast. To play them continuously, transfer the files to a Storage Box or server, then run a separate playback and encoding process on an always-on host that sends a live feed to YouTube.
The distinction matters overnight: an SFTP transfer can finish successfully while no broadcast is running. This guide separates those jobs, explains which Hetzner destination fits, and shows where YouTube’s stream settings and your own monitoring fit into the workflow.
Separate the upload from the broadcast
Think of the setup as two stages. First, move source video files from your computer to a place your playback process can read. Second, run that playback process with an encoder that turns the selected video and audio into a live feed for YouTube. SFTP and SCP do the first job; neither protocol creates a live stream.
YouTube describes an encoder as converting video into a digital format for streaming. In practice, the encoder needs an input, such as a video file or playlist, and YouTube’s ingest details: a stream URL and a stream key. A file sitting in a Hetzner account is not an input YouTube can fetch by itself. Something must read it and send the feed.
Before choosing a destination, decide where that second-stage process will run. A Hetzner Storage Box can hold files, while a Hetzner Cloud server can run software and maintain a process. You might use both: store a larger library on the Storage Box and run playback on a separately configured server. The server must be able to access the source files and send an outgoing feed to YouTube.
For a broader view of the compute side, see this guide to choosing a low-cost VPS for a church stream in India. It can help frame the hosting decision, but no general recommendation replaces testing your own media, network path and chosen playback software.
Choose a Hetzner destination
A Storage Box is a file-hosting destination. Hetzner documents SFTP and SCP access for transferring files, but a Storage Box is not a general-purpose shell account where you can install and run an encoder. A Cloud server is a different product: you administer an operating system and can set up a playback and encoding stack there, subject to the server’s resources and your own maintenance.
| Destination | What it is suited to | What it does not do by itself |
|---|---|---|
| Storage Box | Holding and transferring video files over supported file-access methods | Run your playlist player or encode a YouTube broadcast |
| Cloud server | Hosting the playback and encoder process, as well as files if you choose | Automatically ensure your chosen software can encode your media or stay healthy |
| Separate Storage Box and server | Keeping the library apart from the host that broadcasts it | Remove the need to make files reachable and monitor the running process |
If you already have a server with enough capacity for the work, uploading the files there may be simplest. If your collection belongs in a separate storage location, you can upload to the Storage Box and arrange access from the playback host. Keep in mind that transferring a file to one product does not make it automatically visible on the other. Decide how the server will read the files before you upload a large library.
A self-managed server offers control over the operating system, playback logic and configuration. It also leaves you responsible for updates, access security, recovery and availability. A managed prerecorded-live-stream service shifts some of that operating work to a provider, but changes your control over configuration and adds a service relationship to evaluate. Compare the real responsibilities as well as recurring costs; do not choose by a feature label alone.
Enable Storage Box external reachability if needed
If your transfer client is outside Hetzner’s network, check the Storage Box settings in the Hetzner Console. Hetzner’s documentation says external connections require External Reachability to be enabled. Without it, a correct hostname, username and password may still not result in a connection from your home or office.
Use the connection details shown for your own Storage Box rather than guessing a hostname or path from a tutorial. Hetzner documents SFTP and SCP over port 22 for this access. That does not mean you have interactive SSH access to a Storage Box: file transfer access and a shell on a general-purpose server are different capabilities.
For a Cloud server, do not copy these Storage Box assumptions across. Check how its network and firewall are configured, allow only the connections your architecture needs, and secure SSH access. Hetzner’s Storage Box overview and access documentation explains the product’s role; consult the current documentation for the exact controls available on your account.
Transfer files with SFTP or SCP
For a graphical workflow, use an SFTP client such as WinSCP or FileZilla. Enter the host and account details Hetzner provides, select the supported authentication method, and transfer the files into a clearly named directory. A command-line SFTP or SCP client can do the same job if you are comfortable using a terminal. The choice of client changes how you operate the transfer, not what it accomplishes.
When a client presents a server host fingerprint, verify it against an independent, trusted source before accepting it. Do not treat a prompt as a routine button to click through, particularly when transferring valuable files or entering credentials. Use a password or SSH key only as supported for the destination, and keep private keys protected.
Avoid putting passwords or YouTube stream keys directly into commands that might be saved in shell history, copied into notes, or exposed in screenshots. Transfer credentials and broadcast credentials are separate secrets. A file-transfer login should not be reused or published as though it were a harmless setting, and the YouTube stream key should be treated like a password.
After upload, compare the local and remote file lists and check that transfers completed rather than assuming every item arrived. Open representative files in the playback environment, including one with the longest duration or most demanding video and audio combination in the planned playlist. A transfer can be complete while a media file is still unsuitable for the player or encoder you intend to use.
A useful directory scheme might separate source files, processed versions, and playlist notes. Keep filenames predictable and avoid changing a file while it is being read for broadcast. If you later replace an item, verify that the playback process sees the intended version. For help thinking through a source sequence rather than a single loop, see how to schedule different videos in a 24/7 channel.
Prepare playback and encoding on an always-on host
The playback host is where the files become a programme. It needs software that can read your media in the intended order, hand that output to an encoder, and keep the process running for the period you require. You can choose a suitable player and encoder, but verify their current documentation for playlist behaviour, file formats, process supervision and recovery before settling on an implementation.
The reviewed Hetzner and YouTube guidance does not validate a particular command for continuous looping, nor does it establish a server size for a specific resolution. Avoid copying a command from a forum and treating it as a tested 24/7 deployment. Check the player and encoder’s primary documentation, then test the exact files, order, transitions and output settings you plan to use. A configuration that handles one short file is not evidence that it will handle a long playlist without gaps.
You also need to decide what happens when a process exits, a file cannot be read, or the server reboots. Choose a supervision and restart approach documented for your operating system and software, and test it deliberately. Confirm that recovery does not leave two competing broadcasts, skip the intended sequence, or expose a secret in logs. Continuous operation is an operating plan, not just a playback command.
If the files live on a Storage Box, establish and test how the server will access them before relying on that arrangement. Check permissions and connectivity, and consider what the player does if the connection drops during playback. If the files are local to the Cloud server, plan disk capacity and backups instead. In either case, monitor the host, the process and the outgoing network connection; a reachable server is not proof that YouTube is receiving useful audio and video.
Self-hosting gives you more direct control, but the responsibility is yours for security updates, credentials, recovery and availability. If you would rather avoid operating a playback host, a managed option may suit you better. StreamNeo removes the work of keeping your own computer on to feed a prerecorded file into a YouTube broadcast, but it is YouTube-only and does not change your responsibility for channel eligibility or content rights.
For a self-managed route, the Debian VPS and FFmpeg setup guide is a useful next reference. Treat it as a separate implementation guide, and still check the current documentation for the exact software version and test your planned playlist; no guide should be read as a guarantee of uninterrupted playback.
Send the encoder feed to YouTube Live
First check that your channel can livestream. YouTube says livestreaming requires a verified channel with no livestreaming restriction in the past 90 days; its getting-started guidance also states a minimum age of 16. Eligibility can change or depend on account status, so check the current YouTube Live requirements before building around a broadcast plan.
In YouTube Studio’s Live Control Room, create or select a stream and obtain the stream URL and stream key for the encoder. YouTube says to protect the key like a password. Enter it only in the appropriate encoder configuration, do not publish it in a script or screenshot, and reset it through Live Control Room if you believe it has been exposed.
Use RTMPS if your encoder supports it. YouTube recommends this encrypted form of RTMP for ingest. Its general encoder guidance lists H.264 video, constant bitrate encoding, a recommended two-second keyframe interval that should not exceed four seconds, and AAC or MP3 audio. These are YouTube’s platform recommendations, not proof that your chosen server can encode a particular resolution in real time. Start with settings your player and host can sustain, then check the Live Control Room’s preview and diagnostics.
YouTube also documents HLS ingest as an alternative where supported. Its constraints include HTTPS POST or PUT, TS segments lasting one to four seconds, and a rolling ingest playlist with no more than five outstanding segments. That playlist is part of the ingest protocol, not your list of prerecorded source videos. Unless you specifically need HLS and have verified support in your encoder, keep the distinction clear and configure the ingest method your setup actually uses.
YouTube’s encoder instructions are available in Create a YouTube live stream with an encoder. Follow the current page for the interface and supported settings rather than relying on old screenshots. Once the encoder connects, check the preview before making the stream public, and confirm the picture, sound and sequence are what you intend viewers to receive.
Test sequencing and continuous playback
Test more than whether the first frame appears. Watch enough of the sequence to confirm that the intended next file follows, audio does not disappear at transitions, and the loop returns to the beginning as expected. If the playlist includes devotional songs, ambience or local information clips, listen and watch for silence, abrupt cuts, incorrect aspect ratio and any item that should not be repeated.
Run a realistic trial long enough to encounter the transitions and recovery cases that matter to you. Check the server’s process state and resource use while the encoder is active, and inspect YouTube Studio for ingest warnings or a stalled preview. Then test the failure paths you can safely reproduce: stop the playback process, restore it, and confirm the documented recovery method behaves as intended. Do not infer round-the-clock reliability from a brief successful preview.
Plan for the broadcast to need attention. Decide who will receive alerts, how they will check YouTube Studio, and what they should do if the host, file access or network stops working. Keep a copy of original media and configuration notes somewhere independent of the running host. Updates and changes should be made with a recovery path in mind, rather than during an unattended period without a way to check the result.
If retaining a YouTube archive matters, plan it separately. YouTube’s encoder help says streams under 12 hours are automatically archived; do not assume a continuous broadcast exceeding that duration will be archived for you. Keep a local recording or another suitable archive plan if you need a retained copy, and verify storage capacity and rights before recording or republishing material.
You remain responsible for having the necessary rights to every video and audio element, including music, and for following YouTube’s Community Guidelines and applicable laws. A prerecorded loop is still a livestream for these purposes. Check YouTube’s live streaming policies and the current account guidance, especially before scheduling material you did not create or license.
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 broadcast straight from a Hetzner Storage Box?
A Storage Box is for file access and transfer; it is not the encoder or a general-purpose server running your playlist process. You need an always-on playback and encoding host that can read the files and send the feed to YouTube.
Does uploading with SFTP start the YouTube stream?
No. SFTP or SCP transfers files to the destination. A separate player and encoder process must read those files and connect to YouTube Live using the stream URL and protected key.
Can I use a Cloud server instead of a Storage Box?
Yes, if you configure the Cloud server to store or access the media and run the playback and encoder software. You then own its security, updates, process recovery and monitoring; test the exact setup rather than assuming the server is sized for your format.
Will YouTube archive an always-on stream automatically?
YouTube says streams under 12 hours are automatically archived. Do not rely on that for a continuous stream that exceeds the stated duration; arrange a separate recording or archive plan if you need to retain it.