A Hetzner Cloud Volume gives your Cloud Server a place to store source videos separately from its main disk. To use those files in a YouTube loop stream, attach and mount the volume on the server, then configure the encoder running there to read and repeat the files.
The volume does not encode or publish a stream. Your encoder reads media from the mounted path and sends an audio-video feed to YouTube; YouTube presents that feed as a live broadcast. The distinction matters when you troubleshoot: a missing file is a storage or mount issue, while a missing feed is an encoder, network or YouTube setup issue.
Separate storage from the streaming job
A Cloud Volume is networked block storage attached to a Hetzner Cloud Server. Before ordinary files can be stored on it, it needs a filesystem and a mount point: a directory through which Linux makes the volume’s contents available. Hetzner’s Cloud Volumes overview describes volumes as additional storage for Cloud Servers and explains their attachment and capacity characteristics.
The server runs the encoder or playout software. That process opens source files from the mounted directory, processes them into a live feed, and sends the feed to YouTube using the channel’s ingest details. YouTube’s Live Streaming API concepts distinguish the stream, which carries audio and video, from the broadcast, which is the event viewers watch. If you use OBS or another application through YouTube Studio, you can work with those tools rather than calling the API directly.
This arrangement can help when the media library is larger than the server’s main disk or when you want source media kept in a separate storage device. It also adds a dependency: the volume must be attached and mounted, and the encoder must have permission to read it. A volume alone does not make a channel continuous. The process, mount, network connection, and YouTube event all need their own checks.
For the playback side, first decide whether the channel repeats one file or rotates through a playlist. The practical difference is in the encoder configuration, not the volume. A single long devotional recording may be a straightforward loop; a local news channel may need an ordered set of clips and a deliberate update process. This guide covers the storage path and the hand-off to the encoder; use the encoder’s own current documentation for the exact loop syntax.
Create the volume in your project
In Hetzner Console, open the project containing the Cloud Server that will run the encoder, then create a Cloud Volume. Choose a capacity based on the media you intend to store, allowing room for new material and any working files rather than sizing only for the files you have today. Hetzner lists volume sizes from 10 GB to 10 TB and allows volumes to be increased but not reduced; these are product specifications, so confirm the current details on Hetzner’s site before creating one.
A volume can be attached to one server at a time. Hetzner lists a maximum of 16 volumes on one Cloud Server. These are not reasons to provision the maximum: a single volume may be simpler to manage if one server holds the library, while separate volumes can make sense when you deliberately separate data or responsibilities. Check the current documentation for availability in the server’s location before you create resources.
When creating the volume, select the same project and a suitable location for the intended server. Review whether the console offers automatic formatting and mounting or whether you prefer to configure the filesystem yourself. The automatic path is usually the simpler route for a new, dedicated volume. Manual setup gives you control of the filesystem and mount point, but asks you to identify the right device and handle persistence after a reboot.
Storage capacity and recovery are separate decisions. A larger volume gives more room for source files; it does not by itself create a recoverable copy if media is deleted or the volume becomes unusable. Keep a separate copy of irreplaceable video on another storage system or location, and test that you can retrieve it. Hetzner’s documentation says its Cloud Server backups and snapshots exclude attached volumes, so do not assume a server backup contains this library.
Attach it to the encoder server
After creation, attach the volume to the Cloud Server that will run the encoder. Confirm the server identity before proceeding, particularly if the project contains a test server and a production server with similar names. The volume is storage for that server; it is not a direct connection from the volume to YouTube.
Once attached, the operating system should be able to identify the new block device. If you are connecting to Linux for the first time, first check Hetzner’s volume creation and attachment instructions. Do not copy a device name from an unrelated tutorial and assume it will be the same on your machine. Device names can differ, and formatting the wrong disk can destroy data.
Before running any filesystem command, inspect the machine’s block devices and their properties, including size, model or serial where available, and existing mount state. Compare those details with the volume you created. If the device contains data you need, stop and investigate rather than formatting it. A new, empty volume can be formatted as part of setup, but a formatting command is destructive to the selected device’s existing filesystem contents.
Treat the encoder server as the one that must see the volume. If you later move the volume to another server, plan for the change in attachment, mount configuration, permissions and encoder path. A running process cannot read source files from a device that is no longer available to its server.
Choose automatic or manual filesystem setup
For a new volume, automatic setup reduces the number of Linux storage decisions you have to make. Hetzner’s documented automatic options include EXT4 and XFS, and the overview gives the automatic mount path as /mnt/HC_Volume_${VOLUME_ID}. Use the actual path shown for your volume rather than typing the placeholder literally. The console workflow can format and mount the volume as part of setup.
Manual setup is useful when you need a particular mount directory, want to apply a consistent server configuration, or already manage filesystem setup through your own process. The trade-off is that you must correctly identify the volume, choose and create a filesystem if appropriate, mount it, and arrange for it to be mounted again during boot. Hetzner’s Linux volume tutorial and current console guidance should be checked before you follow commands, since the device path must match your own server.
| Choice | What it gives you | What you need to watch |
|---|---|---|
| Automatic setup | A shorter path to a formatted and mounted volume; documented filesystem choices include EXT4 and XFS. | Keep the path Hetzner provides stable in the encoder configuration and verify it is mounted before copying media. |
| Manual setup | Control over filesystem choice and mount point, such as /mnt/videos. |
Correct device identification, safe formatting, mount configuration and reboot persistence are your responsibility. |
For a video library used by one encoder, either filesystem can provide an ordinary directory path once mounted. Do not choose EXT4 or XFS on the assumption that one will make YouTube streaming faster; the supplied documentation does not establish that. The choice should fit your administration practice and any other requirements for the server.
Hetzner lists up to 5,000 sustained read/write IOPS and 200 MB/s sustained throughput, with burst limits up to 7,500 IOPS and 300 MB/s. These are provider specifications, not a promise that a particular encoder workload will reach those figures. A simple loop reading one file has a different pattern from several processes repeatedly reading a rotating library, and other parts of the server may be a limiting factor.
Mount the volume and place source videos
A mount point is a directory where the mounted filesystem appears. With automatic setup, use the path assigned by Hetzner. With manual setup, create an intentional path such as /mnt/videos, then mount the verified device there. If you want a manual mount to return after a reboot, configure it using /etc/fstab and validate that configuration before relying on it. A mount that exists only because you entered a command after boot will not be present automatically on the next boot.
Before copying a large media library, verify that the volume is actually mounted at the intended path. Tools such as findmnt and df -h can show the mounted filesystem and available capacity. This check prevents a common operational mistake: if the volume is absent, the mount-point directory can still exist as an ordinary directory on the server’s root disk. Copying into it can fill the root disk instead of the volume.
Create a dedicated directory for the channel’s media, for example /mnt/videos/channel-a, and copy the source files there. Keep filenames and folder structure stable if your encoder configuration refers to individual files or playlists. After copying, check that the expected files are present and that the user account running the encoder can read them. Linux file ownership and permissions apply to files on the mounted volume as they do elsewhere.
Consider keeping source files distinct from temporary outputs, logs and encoder recordings. That separation makes it easier to see what the channel is supposed to play and reduces the chance of a playlist picking up a partial file or an archive recording by accident. If new files are added while the channel is running, follow the playback tool’s documented method for reloading its playlist rather than assuming it will notice automatically.
The media path is also a useful boundary in your own notes: write down the mount point, the content directory, the account that runs the encoder and the backup location. If another person has to recover the channel after a restart, those facts are more useful than a generic reminder that the files are “on Hetzner”.
Point the encoder at the mounted path
Configure the encoder or playout process running on the Cloud Server to read from the mounted directory. The path should be the full, stable path, such as /mnt/videos/channel-a, not a desktop path from the computer where you prepared the files. If the process runs under a separate system account, test access using that account; being able to see the files in your own shell does not prove the service can read them.
Next, set the desired playback behaviour in the encoder: repeat a single file, or repeat a playlist in the order you specify. The exact option depends on the software and version. For an FFmpeg-based workflow, consult the current FFmpeg documentation for the input and loop options you choose. For OBS or a dedicated playout application, use its current documentation and confirm how it handles a missing file, a playlist change and a process restart. The storage documentation establishes where the files are, not the correct loop setting for every encoder.
A useful test is to start the playback process locally or in a controlled test broadcast and confirm that the intended file is being read. Verify both picture and sound, especially where video files have different audio levels, aspect ratios or durations. If the feed stops at the end of a clip, the loop behaviour may not be configured as intended. If it goes black after a reboot, check mount ordering and file permissions before changing YouTube settings.
For a repeating product walkthrough, the guide to repeating a demo on YouTube Live without a gap is useful for thinking about the transition between files. If you are building a music station rather than a single-file loop, see the FFmpeg music-stream setup guide for a separate discussion of encoder workflow. The server and operating system in that guide differ, so do not copy its paths or commands as if they were Hetzner volume instructions.
Keep the mount and media recoverable
A manual mount configured only for the current session needs attention after a reboot. Configure a persistent mount if the encoder is expected to start after the server does, and test the sequence deliberately: reboot during a maintenance window, confirm the volume mounted at the expected path, then confirm the encoder can read a file. Arrange the encoder’s start order so it does not attempt to open a path before the mount is ready. A service supervisor or scheduled restart can help manage a process, but it cannot make an absent volume’s files available.
Before putting the channel into routine use, test what happens if the volume is temporarily unavailable or the mount fails. A stale or empty directory at the expected path can be misleading because the pathname still exists. Use a mount check in your operational procedure, and pause encoder startup if that check fails. This is especially important where a script automatically restarts a stopped process: restarting repeatedly against missing media does not repair the mount.
Keep an independent copy of source material. Hetzner describes replication of volume data across physical systems, but that is not a user-controlled backup or a restore point. Its documentation explicitly says volumes are not included in server backups and snapshots. A backup in another location protects against accidental deletion or a damaged source library; periodically test restoring a file rather than relying only on a successful copy job.
If you need more capacity later, Hetzner allows increasing a volume but not reducing it. After increasing the provider-side size, the operating system filesystem may also need to be enlarged before the added space is usable. Confirm the current vendor procedure for your filesystem before doing this. Avoid filling the volume to its limit: leave room for the next upload and any temporary files your workflow creates.
For a more general discussion of storage pressure in a continuous encoder workflow, the FFmpeg disk-usage guide can help you distinguish source-media capacity from logs and generated files. Its advice is not a substitute for confirming where this particular volume is mounted.
Verify the YouTube live feed
Before going live, confirm that the channel is eligible to live stream and that the encoder has the correct ingest details. YouTube’s live streaming eligibility guidance is the place to check current channel requirements; do not assume that a correctly mounted volume makes the channel eligible. In YouTube Studio, configure or select the broadcast and stream as appropriate for your workflow, then use the encoder’s test or preview path before starting the event for viewers.
Look at the encoder’s own status as well as YouTube’s preview. Confirm that the process is reading the intended file from the mounted path, that the picture and sound reach YouTube, and that playback continues as expected when a file ends or a playlist advances. A local process saying “running” does not prove the viewer-facing broadcast is receiving the right content.
YouTube’s API lifecycle documentation describes creating a broadcast and stream, binding them, testing and going live. It is written for API workflows; if you use Studio and a desktop or server encoder, the interface may handle those steps for you. Either way, keep the concepts straight: the server-side volume stores source files, the encoder sends a live feed, and the broadcast is what viewers see. For a multi-day channel, also read about how long a YouTube live stream can run and plan monitoring and recovery around the current platform behaviour rather than assuming a stream will stay live indefinitely.
If the feed fails, isolate the layer. First check whether the expected mount is active and the source file is readable. Then inspect the encoder’s input and output status, followed by the YouTube preview and broadcast status. This order avoids changing stream settings to solve what is actually a missing file, or remounting storage when the encoder is simply pointed at the wrong path.
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
Does a Hetzner Cloud Volume send video to YouTube?
No. The volume stores source media attached to a Cloud Server. An encoder or playout process on that server reads the files and sends the live feed to YouTube.
Should I choose automatic or manual setup?
Automatic setup is a simpler route for a new volume when its documented filesystem and mount path suit your needs. Choose manual setup when you need control of the filesystem or mount point and are prepared to identify the device, configure the mount and check reboot persistence.
Will the volume still be mounted after the server restarts?
Automatic setup or a persistent manual mount can make the volume available after boot, but verify the mount and encoder start order on your own server. If the mount is absent, the directory can still exist on the root disk without containing the volume’s files.
Are the videos covered by Cloud Server backups?
Hetzner states that backups and snapshots for servers do not include attached volumes. Keep a separate copy of important source video and test that you can restore it.