To run an always-on YouTube radio stream on an Ubuntu VPS, use FFmpeg to combine your audio with a static image or looping visual, then publish the feed to the current RTMPS address and stream key shown in YouTube Live Control Room. A VPS can keep the encoder process running independently of your home computer, but it cannot guarantee uninterrupted playback: the process, network, YouTube ingest and channel status can each fail.
The practical approach is to make each part observable and recoverable. Prepare compatible media, protect the stream key, supervise FFmpeg with a service manager, check YouTube’s stream health, and decide how you will handle source exhaustion, restarts and archives before treating the channel as a station.
How the VPS radio stream is assembled
The arrangement has four parts: audio and visual source files, FFmpeg, an Ubuntu VPS with a sustained outbound connection, and the YouTube Live event. FFmpeg reads the sources, encodes a live audio-video output and sends it to the ingest endpoint using RTMPS. Viewers receive the feed through YouTube; the VPS is the publisher, not the viewing platform.
For a radio format, the visual need not be elaborate. You might pair a devotional music programme with a channel image, or place a slowly moving waveform over a loop. A still image is lighter to prepare and avoids video-motion choices, while a loop can better fit the station’s identity but brings additional file and continuity checks. In either case, there must be video as well as audio for the intended live video feed.
The whole chain matters. A working FFmpeg process does not prove that the feed is arriving, that YouTube accepts it, or that the watch page is displaying the expected image and sound. Likewise, a successful connection at the start does not prove a long session will survive a VPS reboot or an interrupted route. Keep these separate questions in mind: is FFmpeg alive, is it sending, and does YouTube report a healthy stream?
If you are choosing between a VPS workflow and a playlist-based approach, first decide whether you need custom audio handling and direct control of the encoder. A VPS means you take responsibility for Linux updates, process supervision and monitoring. For broader channel scheduling, a seasonal playlist schedule for a YouTube 24/7 channel may help you plan the programming independently of the publishing method.
Prepare audio and video inputs
Start with media that you have permission to use and that FFmpeg can read. Keep the working files in a directory owned by the account that will run the stream, rather than placing them in a public web directory. Give files clear names and keep a separate copy of the originals. Before setting up a long session, play the complete intended programme locally or inspect it for silent gaps, corrupt sections and unexpected endings.
For a single track or pre-produced programme, a finite file is simple to test, but it eventually ends. A continuous radio sequence needs an explicit way to provide the next audio segment or repeat material. Do not assume that a file will loop merely because the process stays running. Confirm the chosen FFmpeg input and filter behaviour with the actual files, and test what happens at the end of each item. If transitions matter, prepare and listen to them in advance; the notes on fading between tracks in a 24/7 YouTube lofi stream are relevant to that part of the programme design.
A static visual can be used alongside audio, or you can use a video loop. Consider whether the image dimensions and frame rate are appropriate for your chosen output, and verify that the combination remains visible while the audio continues. A still image saves work but can appear frozen by design; if viewers might mistake that for a fault, include a restrained clock, title card or other permitted movement in a loop instead. Avoid adding movement solely to make an encoder graph look busy.
Test CPU use as well as playback. Encoding settings that seem reasonable on a desktop may place a different load on a small VPS. Use a representative test with the final audio, visual and output settings; inspect CPU and network use while FFmpeg is running. There is no universal VPS size established for every stream. The actual requirement depends on the selected video settings, software build, and the machine’s available resources.
Find the current YouTube ingest details
First check the current YouTube Live eligibility requirements for the channel. YouTube’s live streaming eligibility guidance includes channel verification and a restriction check; requirements can change, so confirm them in the official help page rather than relying on an old tutorial. Create or schedule the live event in Live Control Room, then open its stream settings.
Copy the RTMPS URL and stream key from that event’s settings. They are account-specific connection details, not values to borrow from an example command. Use the RTMPS address currently displayed by YouTube, rather than an ordinary RTMP address copied from an older guide. YouTube recommends RTMPS for encrypted transport, and its RTMPS developer documentation explains the ingest protocol and connection details, including the use of port 443 and the hostname during TLS authentication.
Keep the key private. Do not put a real key in an article, shared shell history, public source repository, screenshot or log that other people can read. A command line containing the key can be recorded in shell history and may be visible to other local users or diagnostic tooling. Store it in a root- or service-account-readable configuration file, or another suitable secret-handling mechanism, and keep permissions narrow. If the key is exposed, use YouTube’s controls to replace or reset it and update the service configuration.
The event and its stream configuration are distinct from FFmpeg’s local process. A successful encoder start is not a substitute for checking that the right event is selected and available. Use an unlisted or private test where appropriate, confirm the preview and audio in Live Control Room, and only then make the intended event public. A practical private test of a YouTube live loop can reveal problems without turning a configuration check into a public broadcast.
Configure FFmpeg to publish the feed
FFmpeg’s protocol documentation demonstrates reading a file in real time with -re and writing FLV output to an RTMP server. YouTube’s ingest workflow uses RTMPS, so treat the documentation’s sample as an explanation of the publishing pattern, not as a complete YouTube command. The official FFmpeg RTMP protocol documentation describes the protocol options; check your installed build and test the particular input, codecs and output combination you intend to use.
A command for your setup needs to identify the audio source, the still or looping visual, the video and audio encoding choices, and the RTMPS destination. For a static image, the video input must be kept available for the duration of the audio feed; for a looping visual, confirm its repeat behaviour and that the audio is not cut off when the visual restarts. The output format and codecs must match the current YouTube encoder requirements. Do not paste a copied command without understanding which part specifies each input and which part carries the secret destination.
YouTube’s encoder settings guidance lists RTMP/RTMPS ingest, H.264, H.265 or AV1 video, AAC or MP3 audio, constant bitrate, and up to 60 frames per second. It recommends a two-second keyframe interval, not exceeding four seconds, and stereo audio at 44.1 kHz and 128 kbps. These are YouTube’s current published recommendations and supported settings, not a promise that any individual stream will be accepted. Verify the page before a new setup because guidance may change.
For H.264, the same YouTube guidance gives 3 Mbps minimum and 8 Mbps recommended for 720p30, and 5 Mbps minimum and 14 Mbps recommended for 1080p30. A simple radio image may not need 1080p; choose resolution according to the visual and audience, then test the result. YouTube also recommends approximately 20% upload bandwidth headroom beyond the aggregate stream bitrate. Check sustained outbound capacity from the VPS itself, not only a connection at home. Capacity can vary, and a brief speed test cannot guarantee a stable route for a continuous broadcast.
The trade-off is between visual detail and resource use. A modest image at a lower resolution can reduce encoder work and network demand, while a high-resolution canvas may be useful if the visual contains legible text or detailed artwork. Audio clarity and consistency usually deserve more attention than motion for a radio channel. Make one change at a time, inspect YouTube’s preview and stream health, then record the working configuration without the key.
Run and supervise the process
For an unattended stream, run FFmpeg under a service manager such as systemd rather than leaving it attached to an interactive SSH session. A service manager can start the process at boot and restart it after an exit, while centralising its logs for later review. It is process supervision, not end-to-end recovery: it cannot determine whether YouTube is accepting the feed, whether the key remains valid, or whether a restarted encoder rejoins the intended live event.
Create a dedicated Linux user for the stream where practical. Give it read access to the media and secret configuration, write access only where logs or recordings require it, and no broader permissions than needed. Avoid running a persistent encoder as root. Keep the unit configuration and secret values separate; do not include a real key in a command example, a world-readable service file or a public repository. After changing a secret or service definition, check the permissions and restart procedure deliberately.
Set restart behaviour only after testing it. An automatic restart can help when FFmpeg exits because of a process fault, but repeated failures can produce a restart loop that fills logs or repeatedly contacts an unavailable endpoint. Make the service’s state visible, and decide who will receive an alert if the process keeps failing. Also consider whether a restart after a host reboot should begin immediately, or wait until the media, network and event configuration are ready.
Test the failure cases with an unlisted or private event before depending on the setup. Stop FFmpeg and check that the supervisor notices; restart the VPS and confirm the service starts; interrupt the source or network in a controlled test and observe what FFmpeg and YouTube report. Then check whether a restarted encoder reconnects to the same active event as expected. The behaviour can depend on the current event and account configuration, so do not infer it from a process manager’s restart status alone.
If you would rather not keep a personal computer powered on or manage an encoder process through the night, StreamNeo removes that particular burden by turning an uploaded video into a YouTube live stream that can continue with your computer switched off. It does not change the need to choose content carefully or check that the channel and live event are working as intended.
Monitor the connection and encoder health
Monitoring should answer different questions rather than showing only whether a process exists. On the VPS, check the FFmpeg process, recent log messages, CPU use, memory pressure and outbound network. In Live Control Room, inspect the preview and stream-health indicators. Finally, open the watch page from a separate device or connection and verify that the expected audio and picture reach a viewer.
YouTube’s LiveStreams API documents states such as active, ready, inactive and error, as well as health statuses including good, ok, bad and noData. These are useful clues, not a replacement for viewing the actual broadcast. A process can be active while output is missing, and a status may take time to reflect a problem. Use the LiveStreams resource documentation to understand the API fields if you build your own checks.
If the preview reports a poor connection, compare the encoder’s output settings with YouTube’s guidance and check the VPS’s sustained outbound route. If there is no data, inspect whether FFmpeg started, whether its inputs remain readable, and whether the service is using the current RTMPS URL. For an SSL error or timeout, verify that the URL uses rtmps, the host and application path are correct, port 443 is reachable, and the installed FFmpeg build supports the selected protocol. A hostname matters for TLS authentication, so avoid replacing the supplied endpoint with an IP address.
Define an alert threshold that prompts a human to investigate rather than blindly restarting everything. A process exit may justify a restart; a YouTube-side ingest error may instead call for checking the event or key. Keep logs useful but safe: ensure they do not capture a destination URL containing the key, and restrict access to them. Review logs after a test interruption, as well as after an apparently clean run, so you know which failure messages actually occur in your configuration.
Plan for rights, replays and recovery
Only use music, images and video for which you have the rights needed for this use. A track being available online, or a visual being easy to download, does not establish permission to broadcast it. YouTube’s live-stream terms place responsibility on the creator for necessary rights, including relevant music rights. Keep records of licences and permissions, and check their scope for live transmission, territory, duration and replay availability.
YouTube scans live streams for third-party content. A detected match can lead to a warning, placeholder, interruption or termination. YouTube also notes that a stream can be interrupted even when you hold a licence if the channel has not been added to the rights owner’s Content ID allowlist. Resolve those arrangements with the relevant rights owner before relying on continuous playback; an encoder restart will not fix a rights restriction.
For replays, plan separately from the live feed. YouTube says streams shorter than 12 hours can be automatically archived, while streams longer than 12 hours may not be captured at all. Do not promise yourself or listeners that a 24/7 broadcast will produce one complete replay. If archives matter, consider shorter planned sessions with a deliberate handover, or a separate local recording process. Check disk capacity, file rotation and recording health so an archive task does not quietly consume the space the encoder needs.
Write down a recovery sequence for the common failure points: source file ends, FFmpeg exits, the VPS reboots, outbound connectivity fails, the stream key changes, or YouTube reports an error. Include how to check the Live Control Room, who can access the account, where the secret is stored and how to restart safely. A written procedure is especially useful if someone other than the person who configured the VPS has to respond overnight.
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
How do I stream music to YouTube 24/7 from a VPS?
Prepare audio and a still or looping visual, configure FFmpeg to encode them as a live feed, and publish to the current RTMPS address and key from YouTube Live Control Room. Use a process supervisor and monitor both the VPS and YouTube’s stream health; no single setting guarantees continuous playback.
Can systemd keep an FFmpeg YouTube stream running?
Systemd can start FFmpeg at boot and restart it after a process exit, which helps with one class of failure. It cannot confirm that YouTube is receiving acceptable media or that the live event reconnects correctly. Test restart and reconnection behaviour with your account before relying on it.
Does YouTube save a complete replay of a 24/7 stream?
Not necessarily. YouTube says streams longer than 12 hours may not be captured at all, so a continuous station should not rely on one complete archive. Use shorter planned sessions or a separate recording process if replay copies matter.
Why use RTMPS instead of RTMP?
YouTube recommends RTMPS, which adds encrypted transport to the connection between encoder and ingest. Use the current RTMPS endpoint supplied in Live Control Room and protect the associated stream key.