A 24/7 YouTube radio stream with static artwork is a live video broadcast whose picture is a still image and whose sound comes from your audio source. On Hetzner, you run an encoder on a Linux cloud server, configure it with YouTube’s RTMPS ingest details, and keep the process running while you monitor it.
The pieces have different jobs: YouTube provides the live event and ingest endpoint, your VM provides a place to run the encoder, and the encoder combines image and audio into a continuous output. The steps below separate those jobs so you can test each before relying on the stream overnight. The command and server choices are examples to evaluate, not a tested radio recipe or a minimum specification.
Check YouTube Live eligibility and prepare the event
Start with the channel, not the server. YouTube’s current live streaming eligibility guidance says a channel must be verified and must not have had live-streaming restrictions in the previous 90 days. It also says the person livestreaming must be at least 16. Check the official page before planning a launch, because channel status and YouTube’s requirements are what determine whether you can go live.
Once eligible, open YouTube Studio’s Live Control Room and create or configure the event. Choose whether the stream is public, unlisted or private, set its title and other details, and select the encoder workflow. YouTube will show a server URL and a stream key for the event. The encoder sends its output to that destination; it does not create the event for you.
Treat the stream key as a password. Anyone with access to it may be able to send content to the associated stream, so do not publish it in a script repository, send it in a public support post, or put it in a screenshot. Store it somewhere access-controlled and use a method that keeps it out of shell history where possible. If it is exposed, replace or reset it through YouTube Studio before resuming.
A static picture does not make this an audio-only broadcast from YouTube’s perspective. You are sending live video with an image track and an audio track. Plan the event’s title, description, visibility and artwork accordingly. If you are still deciding between a server and a computer you already own, this guide to moving a 24/7 music stream from a PC to a VPS helps frame the operational change: the computer stops being the machine that must remain on, but server administration becomes your responsibility.
Choose and provision a Hetzner Cloud Linux server
Create a cloud server in Hetzner’s control panel and select a Linux image, location, server plan and networking options. Hetzner documents locations in Europe, the United States and Singapore; a nearby location is a sensible starting point for a small project, though the audience’s location and your own administration needs also matter. A public IP is needed for ordinary public network access. Review the current Hetzner Cloud server documentation and the plan display while provisioning rather than relying on a remembered price or resource combination.
There is no validated minimum VM size for this particular radio workload in the research behind this guide. Do not treat a suggested vCPU or memory figure from an unrelated video workload as proof that it will encode your source reliably. Actual demand depends on the encoder, output format, image handling and whether hardware acceleration is available and configured. Choose a reasonable starting plan based on current provider options, then check actual CPU and memory use during a representative test. Hetzner says resource types can be rescaled, but resizing is an operational change to schedule and verify rather than a substitute for measuring.
Compare the plan on more than its headline compute figure. Check the selected location, whether the network configuration assigns a public IPv4 address, the included outgoing traffic and any additional costs for backups or snapshots. Hetzner’s billing information says server resources remain billable while the server exists even if it is powered off, and outgoing traffic is what its Cloud billing model charges for. Check the current Hetzner pricing page before you commit; prices and allowances can change, so this article does not quote them.
Apply the provider’s access controls as part of provisioning. A Hetzner Cloud Firewall blocks inbound traffic that does not match an allow rule; when there are no outbound rules configured, outbound traffic is permitted. For an encoder VM, allow only the administration path you actually need, such as SSH from a known address if that is workable for you, and avoid opening unrelated inbound ports. The stream itself is an outbound connection to YouTube. Verify the required path against your current encoder and provider configuration rather than adding broad inbound access as a guess.
Hetzner’s Cloud Firewall guide explains its rule behaviour. Keep a way to regain access before tightening rules, and test administration after applying them. If a firewall rule blocks your remote login, the stream may continue for a time but you will have made troubleshooting harder.
Prepare the audio source and static artwork
Decide exactly what the audio source is before configuring the encoder. It might be a single long file, a prepared sequence of tracks, or a programme feed that can be read continuously. The encoder needs a source that remains available and produces audio for as long as you expect the broadcast to run. A playlist that reaches its end, a file that cannot be read after a reboot, or a remote feed that drops can leave the video process without useful sound even if the VM is still running.
Keep source files in a location the server can access consistently, and document how they are updated. If you upload a new programme, make sure the encoder can read it and that replacing it will not interrupt a live process unexpectedly. Use audio you have the right to broadcast on YouTube; a live channel does not change the permissions attached to music or recordings. This is an editorial and rights check for you to make, not something a server setting can settle.
Prepare a clear, legible image in a format your encoder can read. Consider how it will look on a phone as well as on a television: a small channel name or schedule can disappear at reduced size. Static artwork is not a guarantee that viewers will understand what is playing, so useful visual information might include the station name or a short description, without promising that a particular track is currently on air when you cannot keep that information accurate.
Make a copy of the image and audio outside the VM if losing the server disk would take away your only copy. Hetzner offers backups and manual snapshots, but these are recovery aids for the server disk, not a live-stream failover mechanism. Its backup documentation describes daily backups with seven slots per server and manually created snapshots retained until deleted; confirm the current terms on Hetzner’s backup and snapshot documentation. Attached volumes are excluded from those backups, so files on a volume need their own backup plan.
Configure an encoder to combine audio and artwork
The encoder’s job is to produce a live output with a still-image video track and your chosen audio input. YouTube supports encoder-based livestreaming, and its live encoder settings provide the settings to use as a reference. YouTube lists H.264, H.265/HEVC and AV1 video support, frame rates up to 60 fps, a recommended two-second keyframe interval that should not exceed four seconds, constant bitrate encoding, and AAC or MP3 audio. Its bitrate guidance varies by resolution and frame rate. Select an output profile that suits the artwork, available upstream capacity and intended viewing quality rather than assuming one bitrate fits every radio stream.
For a still image, a modest output resolution may be adequate, but that is a choice to test, not a special YouTube radio requirement. Lower output demands can reduce the upload capacity needed, while higher resolution may help where the artwork contains small text. A still picture also has little motion, but do not infer from that alone that a particular low bitrate will pass YouTube’s ingest checks or look acceptable to every viewer. YouTube’s own guidance says it will detect the encoder settings and transcode a live stream into different output formats for viewers; that does not remove the need to send a valid, stable input.
The research for this guide does not validate a radio-specific FFmpeg command, automatic reconnect flags, playlist rotation logic or a process supervisor configuration. If you use FFmpeg, treat any command you assemble from its current documentation as an example to adapt and test, not a recipe proven here. In broad terms, the inputs are the artwork and audio source; the output is a continuously encoded stream directed to YouTube’s RTMPS URL with the event’s key. Confirm that the chosen encoder supports the input formats and options you have, and that the command does not expose credentials in logs or process listings unnecessarily.
You can use a process manager or service unit to start an encoder at boot and restart a process after an exit, but that only addresses one failure mode. It cannot repair a bad audio file, expired key, blocked network route or a YouTube event that has ended. Set up the service after the basic encoder has been tested in a controlled session; otherwise multiple layers make it harder to identify whether a failure comes from the input, command, network or process manager.
If you prefer not to maintain a Linux encoder process and its recovery routines yourself, StreamNeo removes that particular burden by turning an uploaded video into a YouTube stream that runs with your computer switched off. It is YouTube-only, and that does not change the need to prepare suitable content and check the channel and event settings.
Set YouTube RTMPS ingest details securely
YouTube’s encoder workflow supplies a server URL and stream key in Live Control Room. Configure your encoder with those values for the event you intend to run. RTMPS is RTMP carried over TLS/SSL, and YouTube recommends secure RTMPS delivery for ordinary user content. Use the exact endpoint shown for your event rather than copying an old URL from a different stream or a third-party tutorial.
Keep the destination and key separate in your notes so you can rotate the key without rebuilding the rest of the configuration. Avoid pasting the key into a public issue tracker or a command that will be saved in shell history. If you need to transfer the configuration to another administrator, use a private channel and remove access when it is no longer needed. After changing the key in YouTube Studio, update the encoder configuration as well; a mismatch usually means the encoder cannot authenticate to the event.
The Hetzner VM needs outbound network access to YouTube’s ingest service. Avoid opening inbound ports simply because an encoder tutorial uses them for a different mode. Check current firewall rules and confirm that the server can reach the configured destination. YouTube’s encoder setup instructions show the event workflow, but the precise network rules depend on your chosen encoder and the current provider setup.
Start the encoder and verify the live preview
Before making an event public, run a test session and watch the preview in Live Control Room. YouTube recommends testing before going live and checking stream health. Confirm that the artwork is visible, the audio is audible at a sensible level, and there is no unexpected silence, clipping or repeated error. A still picture can make a broken audio input less obvious from the viewer’s side, so listen to the preview rather than judging the stream only by whether an image appears.
Check the event visibility and access from a second device or account where appropriate. Make sure the scheduled event is the one receiving the encoder output, and that the intended audience can open it. Allow time for the preview and ingest status to update before deciding that the encoder has failed. If the control room reports a health issue, compare its message with the encoder’s own output and the VM’s resource use instead of changing several settings at once.
Test one failure at a time while the stream is not being relied on. For example, stop the encoder process and observe whether your chosen supervisor restarts it; then check whether the preview returns and audio resumes. A separate controlled test can check what happens after a VM reboot. These are tests you should perform in your environment, not results established by this guide. Keep notes of what you changed and what the control room showed so you can repeat the working configuration.
For a genuinely continuous station, make a plan for what the listener hears when the normal programme source ends or is unavailable. A rotating audio playlist is a content workflow as well as an encoder configuration. If you need a playlist to move between tracks or display recent items, this is different from simply holding one still image; see the guide to creating a YouTube live loop playlist for the distinction between a static radio picture and changing programme visuals.
Plan monitoring and recovery limits
A cloud VM can keep running when your own desktop is off, but it does not make the broadcast self-correcting. Decide how you will notice a stopped process, a silent source, a failed connection or an event that YouTube no longer accepts. YouTube Live Control Room provides stream status and health information, and the LiveStreams resource in YouTube’s developer documentation reports stream status and health data. Use the control room for routine checks; use the API only if you are prepared to build and maintain an additional monitoring workflow.
Recovery has layers. A process restart can help when the encoder exits. A VM reboot can help when the operating system or process becomes unresponsive. A snapshot or backup can help restore disk contents after a configuration or disk problem. None of those actions guarantees that a broadcast stays live through a provider outage, loss of network connectivity, or an event-side issue. Restoring a server image is not the same as failing over a live encoder to a second machine.
Hetzner’s backup and snapshot features are useful if you need to restore a known server configuration, but keep copies of irreplaceable audio, artwork and configuration elsewhere too. If you store programme files on an attached volume, account for the fact that Hetzner’s documented backups exclude attached volumes. Before relying on a snapshot, know what it contains, where the original media lives, and how you would restore the encoder configuration without accidentally exposing the stream key.
Budget ongoing costs as well as the initial selection. Hetzner bills server resources while the server exists even if it is powered down, and its Cloud model bills outgoing traffic; cross-zone traffic is treated like other internet traffic in the provider documentation. Check the live plan, IP and traffic terms on Hetzner’s site when you provision, and review them again if the audience or output profile changes. Do not leave an unused VM running just because it is no longer broadcasting.
A sensible first operating routine is to check the preview and audio before a planned launch, confirm that the encoder process is present after any server maintenance, and inspect the event’s status periodically. How often you check depends on how costly an interruption would be for your channel. If a stream must continue despite failures beyond a single VM’s control, you will need a designed failover arrangement and tests for it; a lone cloud server with backups is not that arrangement. A separate always-on computer has its own trade-offs, as described in this spare-PC guide.
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
Is the stream audio-only if the artwork never changes?
No. YouTube receives a live video stream containing a still-image track and an audio track. The picture can remain static, but the broadcast is still a video livestream in Live Control Room.
What size Hetzner server is enough?
This guide does not establish a minimum instance size, and the official material reviewed does not provide a benchmark for this specific workload. Start with a plan you can afford, run a representative test, and measure CPU, memory and network use before relying on it.
Does a Hetzner backup keep the broadcast running if the VM fails?
No. A backup or snapshot can help restore server files, but it does not act as a second live encoder or keep an active broadcast online during a VM or network failure. Plan a separate failover system if continuity through those failures is required.
Can I leave one YouTube event live indefinitely?
Do not assume a single event is guaranteed to remain live without limit. YouTube’s guidance covers live streaming and 24/7 scenarios but does not promise indefinite operation for one event; check current official guidance and monitor the event while it runs.