A VPS can run your radio playout and encode it as an audio-and-video stream for YouTube Live. You configure the station and encoder on the server, then separately create a YouTube broadcast and supply its ingest address and stream key.
This separation matters: a working playlist does not mean YouTube is receiving a valid feed, and a configured YouTube event does not keep your radio running. Treat the VPS as the source encoder, test its full workload, and check the live stream in YouTube before relying on it.
Confirm YouTube Live access and choose a broadcast shape
Before building the server workflow, check that your channel can stream live and that YouTube Studio lets you create a broadcast. Account status, restrictions and the available controls can change, so use YouTube’s current instructions rather than assuming that every channel has the same access. The guide to enabling YouTube Live on a Brand Account can help you understand the account-side preparation, but verify your own channel in Studio.
Decide whether you need one continuous station feed or separate scheduled broadcasts. A continuous feed suits a channel that should present one ongoing radio destination. Separate events may make more sense when you want individual programme pages or distinct schedules. Google’s documentation treats a broadcast and its incoming stream as separate resources; the event is not the same thing as the encoder connection. Read Understanding Broadcasts and Streams when working through that distinction.
For a first setup, create a private or otherwise limited test event if the controls available to your channel allow it. This gives you a place to confirm the picture, sound and stream health without presenting an unfinished station as its public launch. Check the event’s visibility and schedule before you start sending a feed; do not assume that creating an event automatically makes it public or starts the broadcast.
Choose a VPS by testing the complete workload
A VPS replaces a computer in your own premises as the machine running playout and encoding. It does not automatically solve resource limits, network interruptions or configuration errors. No provider or server size can be called adequate from a bitrate alone: Liquidsoap, FFmpeg, the chosen video composition, storage reads and the network connection all contribute to the actual workload.
Compare candidate plans using the provider’s current specifications for processor access, memory, storage, operating system, network transfer and support. Prices and limits change, so check the vendor’s own plan page at the time you choose rather than relying on old comparisons. A low-cost plan may be appropriate for a modest audio-led output, but only a representative test can tell you whether it handles your specific encoder and duration. A more powerful plan can still fail if its outbound network route is unstable or its disk fills.
Test the exact combination you intend to leave running: your audio files, Liquidsoap configuration, video source, FFmpeg settings and destination bitrate. Watch CPU and memory during the test, look for growing process usage, check disk space and verify that the outbound connection remains usable. Repeat with the visual treatment and playlist complexity you expect to use in production. If you change resolution, codec, frame rate or overlays later, test again; those changes can alter the load.
Keep the test long enough to expose behaviours that a quick preview cannot show, such as a playlist transition, a file that fails to decode or a reconnect after a network interruption. This is a workload test, not a promise of uninterrupted operation. If your station cannot tolerate a drop, plan how you will notice and respond to one before publishing the public event.
Prepare audio files and radio playout with Liquidsoap
Organise audio into a predictable directory and confirm that the VPS can read every file under the account that will run the station. Use consistent filenames and avoid relying on files stored only on your laptop. Keep a separate copy of original audio and configuration somewhere you can restore from; the VPS should not be the only copy of the station’s material.
Liquidsoap can manage a radio source and pass audio onwards for encoding. Its book documents approaches involving FFmpeg encoding and a YouTube destination, but treat examples as technical starting points, not guaranteed current copy-and-paste recipes. Confirm syntax for the Liquidsoap and FFmpeg versions installed on your machine. A simple test playlist is useful before adding scheduling, multiple sources or fallback logic.
Start with a small, known set of tracks. Listen to the files individually and then across transitions. Check that levels are consistent enough for comfortable listening, that files are not truncated, and that the playlist behaves as intended when it reaches its end. If your station mixes recorded tracks with live inputs, test each path separately and then test the change between them. Keep automation understandable: a simple source that can be inspected is easier to troubleshoot than a complicated chain whose components you have not tested.
Make failure behaviour deliberate. Decide what Liquidsoap should do if a file is missing, an input becomes silent or a track cannot be decoded. A fallback source can keep audio moving, but it should not conceal a broken library indefinitely. Include a way to recognise the fallback and investigate its cause. For broader channel planning, how to loop a YouTube live stream explains why looping content and running an ongoing encoder are different problems.
Possessing an audio file does not establish that you have permission to broadcast it. Rights depend on the catalogue, territory and intended use, and this guide does not determine what applies to your station. Check the relevant rights and YouTube policies before you put music into a public stream.
Add a video track and configure FFmpeg
A radio stream still needs a video component for this audio-plus-video workflow. A station logo or static image can provide a simple visual; a modest visualiser is another possibility if it is reliable and does not make the video workload excessive. Make sure you have permission to use the image and that it is legible at the output size. Avoid turning a practical radio feed into a complex video composition before the basic audio path works.
FFmpeg can combine a video source with the audio produced by your playout chain and encode the output for YouTube. The exact command depends on how Liquidsoap exposes audio, which video source you choose and the installed versions. Test components separately, then test their combined output. If the audio is present but the video is frozen, the issue may be in the video source or mapping; if the image appears but sound is absent, inspect the audio input and stream mapping.
Choose a supported codec, resolution and frame rate from YouTube’s current encoder settings and bitrate guidance. Its listed options include H.264, H.265/HEVC and AV1 video, plus AAC or MP3 audio. YouTube recommends constant bitrate encoding and a two-second keyframe interval, which should not exceed four seconds. These are encoder requirements and recommendations, not a VPS sizing chart.
For an audio-led station, do not select a high-resolution mode simply because it is available. A static graphic may not benefit from a larger, higher-frame-rate image, while the selected mode can increase encoding and network demands. Match the mode to the picture you need and the capacity your workload test supports. YouTube’s bitrate recommendations vary by codec, resolution and frame rate; use the row for your actual output rather than carrying a number over from another mode. The same settings page lists stereo audio at 44.1 kHz and 128 kbps as recommended values.
An encoder configuration should make its output characteristics explicit: video codec and dimensions, frame rate, keyframe interval, audio codec and rate, and constant bitrate behaviour. Keep a working copy of the tested configuration so you can compare changes. Avoid changing several settings at once; if the next test fails, one deliberate adjustment at a time makes the cause easier to find.
Enter YouTube’s ingest address and stream key
In YouTube Studio, open the broadcast’s stream settings and use the ingest information shown for that event or stream. Configure the encoder with the current server address and stream key from YouTube, not a value copied from an old tutorial. YouTube’s live workflow distinguishes the event from the stream connection, so confirm that the incoming feed is attached to the event you intend to use.
Prefer RTMPS where it is available for your setup. Google’s RTMPS ingestion guide documents the secure ingest endpoint and port 443. YouTube also documents other ingestion protocols, but they have different capabilities; consult its protocol comparison before choosing a different method.
Treat the stream key as a password. Do not put it in a public script repository, paste it into a support forum, show it in a screen recording or leave it in command output that other users can read. Store it separately from the main script with access limited to the account running the encoder. Liquidsoap’s documentation illustrates keeping a key apart from the script; adapt that approach to your operating system and current software. If the key is exposed, replace it using YouTube Studio and update the protected configuration.
On the VPS, keep the service account and file permissions narrow. Anyone who can read the running process configuration or the secret file may be able to use the key. Avoid logging full command lines if they contain credentials, and check what your process manager records. A key should be easy for the station process to read, but not casually visible to every user or copied into backups with weaker access controls.
Test sound, picture, bitrate and reconnection
Run a complete preflight before changing the event to the audience-facing state. Start playout, start the encoder and confirm in YouTube Studio that the incoming stream is detected. Inspect the stream preview and health messages, and listen for the actual audio rather than relying only on a process saying it is running. The FFmpeg setup guide for a 24/7 story stream offers another example of how a file-based source and an encoder fit into a YouTube workflow.
Test with the same kind of audio and movement you expect in the real broadcast. YouTube specifically advises testing ahead of time and monitoring stream health and messages. Check that the image is not cropped unexpectedly, audio is audible on more than one device, and track changes do not create silence or a sudden level jump. Watch the encoder output and YouTube’s incoming status together; either view alone can miss a fault.
Compare the reported bitrate with the output mode and settings you selected. A changing network or incorrect encoder setting can cause the feed to deviate from expectations. Do not treat a displayed bitrate as proof that the picture and audio are healthy: confirm both in playback. If the output is unstable, lower complexity or choose a different supported mode, then repeat the test rather than guessing that the server is at fault.
Test recovery in a controlled way before depending on it. Observe what happens if the encoder process stops, the VPS restarts or the network connection briefly drops. Does the playout return? Does FFmpeg reconnect, or must a supervisor restart it? Does YouTube accept the returning feed on the intended event? Behaviour depends on the software configuration and YouTube’s current controls, so do not assume a restart policy will preserve a public broadcast exactly as you expect.
For connection problems, compare the VPS experience with the local-network issue described in recovering a YouTube stream after an ISP drop. The location differs, but the useful practice is the same: distinguish a source/encoder failure from an interruption between encoder and YouTube, and record what the platform reports before changing settings.
Monitor the VPS and protect the station
A running process is not the same as a healthy broadcast. Check that Liquidsoap is advancing through the playlist, FFmpeg is still producing output, the VPS has free disk space and the YouTube event is receiving audio and video. Decide how you will notice a stopped process or a stream health warning when you are away from the terminal. For a small operation, that may mean a scheduled check and a clear alert route rather than a complicated monitoring system.
Use a process supervisor or service manager if you know how to configure and test it, so a process failure can be detected and handled. Automatic restart can help with a crashed process, but it cannot repair a bad file, exhausted disk, revoked key or continuing network problem. After any restart, confirm the stream in YouTube rather than assuming that a service status of “active” means viewers can hear it.
Apply operating system updates deliberately and retain a tested copy of your station configuration. After a software change, repeat the preflight test because a new version or altered dependency may change behaviour. Keep logs useful but avoid recording the stream key. Document the small number of steps needed to restart, inspect the feed and rotate the key; when a night-time fault occurs, concise notes are more useful than a long shell history.
Running on a VPS means your own computer can be switched off, but it also means you are responsible for selecting, configuring and checking the rented environment. If maintaining playout, encoding and restart behaviour on a server is the part most likely to interrupt your nights, StreamNeo removes that specific server-operation burden by running an uploaded video as a YouTube stream; it is not a Liquidsoap radio-planning tool and is YouTube-only.
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 run an internet radio station on a VPS without a video?
For the audio-plus-video YouTube encoder workflow described here, the encoder should send both audio and video. A static station image is a simple way to provide a visual track, but test that the selected video format is accepted and remains present throughout the stream.
Is Liquidsoap required?
No. Liquidsoap is one documented way to automate radio playout and connect audio to encoding. You can choose another workflow, but test the entire source-to-encoder path and verify that it produces a YouTube-compatible audio-and-video feed.
Which VPS plan should I buy?
There is no plan size in this guide that can be declared adequate without testing your files, encoder settings and expected workload. Compare the provider’s current specifications, run a representative test and check resource use, outbound stability and recovery behaviour before relying on the service.
Does a VPS guarantee the stream stays live?
No. A VPS moves the running workload off your own computer, but process faults, network interruptions, software changes and YouTube-side conditions can still affect the broadcast. Test restart behaviour and monitor the feed rather than treating hosting as an uptime guarantee.