A practical way to stream a regional radio station to YouTube is to run Liquidsoap on a Linux VPS, feed it audio you have permission to rebroadcast, add a simple visual, and send the encoded programme to YouTube Live. The VPS is the encoder and delivery point for YouTube; it does not automatically serve listeners on your own website or app.
There is no universal low-cost VPS tier for this job. The right size depends on the audio source, video encoding, traffic allowance, region and whether the same machine has other responsibilities. Confirm rights, test the actual stream and monitor it before you rely on it overnight.
Map the station’s input and output
Start by drawing the path the programme will take. A common setup is an authorised studio feed or station-owned audio source into Liquidsoap, then an audio-and-visual output to YouTube Live. Liquidsoap can manage internet-radio sources and playlists, and its official overview includes an example of sending a stream to YouTube Live using RTMP and FFmpeg encoding (Liquidsoap’s overview).
Decide which source applies to your station. You might capture an existing station stream, take a contribution feed from the studio, or use a station-owned playlist. These are not interchangeable configuration details. A studio feed may need a fallback to scheduled programming if the contribution drops; a playlist needs a clear rule for what plays next when a file ends. An existing station stream depends on that source remaining available and on permission to retransmit it.
Before building anything, confirm the station controls or has permission to transmit every part of the audio on YouTube, for the intended territories and use. A radio broadcast licence or permission to use one recording may not cover every performer, recording owner, composition, broadcast, or online platform. Keep the relevant written permissions available, and check the current rules that apply to your station rather than assuming that audio already on air can be rebroadcast online.
The output side has two distinct audiences to consider. YouTube needs a live video stream with audio, even if the visual is a still image. If listeners also need a direct audio player on the station’s website, that is a separate service path; do not assume that pushing to YouTube creates an internet-radio mount point for them. The monthly cost planning guide can help you separate the cost of running a continuous YouTube stream from other distribution needs.
Choose a VPS for the actual workload
A VPS is a rented virtual machine, but the word “cheap” does not tell you whether it can encode your chosen output reliably. First list what it must do: receive or read the audio, manage source changes, encode audio, produce or encode a visual stream, and send the result to YouTube. If you also plan to serve listeners directly, estimate and plan for that traffic separately.
For a station that already has an authorised online audio feed, the VPS may only need to receive that feed and prepare the YouTube output. A live studio contribution can add a need for fallback and source-switching behaviour. A playlist with an animated visual asks more of the encoder than audio accompanied by a static image. The point is not that one of these always needs a particular CPU or memory size; measure the workload you intend to run and leave room for the operating system and monitoring tools.
Compare VPS plans by the constraints that affect your job, rather than by headline price alone. Check the CPU capacity and model, memory, included traffic or egress terms, region, recovery features, and total current price. A region close to your station may help with contribution-feed latency, while a route to YouTube ingestion may have different characteristics. Provider and network behaviour vary, so verify the actual plan and test from the location you will use. DigitalOcean’s documentation describes Droplet prices as dependent on configuration; as listed on DigitalOcean’s site in September 2026, it does not identify one plan as suitable for every radio stream (pricing details).
| Workload question | Why it affects the choice | What to check |
|---|---|---|
| Where does audio come from? | A network feed, studio contribution and local playlist have different failure modes. | Network access, input handling and fallback needs. |
| What visual will be sent? | A static image and an animated scene can impose different encoding demands. | CPU use during a representative test. |
| Does the VPS serve listeners too? | Direct listener delivery adds a separate traffic and relay workload. | Egress allowance and a suitable listener-serving design. |
| Where are the contributors and viewers? | Distance and routing can affect contribution delay and delivery paths. | Region options and tests from relevant locations. |
| What happens if the process stops? | An unattended channel needs a way to detect and recover from a failed process. | Monitoring, restart behaviour and access for troubleshooting. |
If you are deciding between a machine you manage and a hosted approach, the spare PC versus VPS comparison explains the operational trade-off. A VPS means you manage the Linux environment and its processes; a computer at the station means the local machine, power and internet connection become part of the broadcast path. Neither removes the need to test recovery.
Prepare Liquidsoap and permitted audio
Install Liquidsoap using the current instructions for your Linux distribution and the version you intend to run. Package names and available features can differ between distributions and releases, so check Liquidsoap’s own documentation before copying configuration from an old tutorial. Keep a note of the version and configuration you deploy, so that later changes can be traced rather than guessed.
Build the source portion before adding YouTube output. If the station uses a playlist, confirm that the files are accessible to the service account and that the playlist behaviour is continuous when it reaches the end. If it uses an authorised network stream, test what happens when the connection pauses or drops. For a studio feed, decide who is responsible for keeping it available and what should take over if the studio is silent or disconnected. These are station policy choices as much as software settings.
Use only audio that the station may transmit in this way. The permitted material might include station-owned recordings, material covered by applicable permissions, or programming for which the necessary rights have been established. Do not treat a publicly reachable radio stream as permission to capture and retransmit it. Rights can depend on the actual repertoire, performers, recordings, broadcast and territories, and this article does not determine the status of any station’s licences.
YouTube scans live streams for third-party content. Its guidance says that a match can lead to a placeholder and warning, and that unresolved content can cause interruption or termination. For licensed third-party material, YouTube advises asking the rights owner to add the channel to its Content ID allowlist; having a licence alone may not prevent a platform interruption (YouTube’s live-stream copyright guidance). Check that guidance and the station’s own permissions before going live. An allowlist request is not a substitute for permissions, and permission should not be assumed to guarantee approval or uninterrupted delivery.
Configure Liquidsoap to produce a continuous audio output that is suitable for the YouTube encoder path. Keep logs useful for diagnosing source changes and failures, but do not put the YouTube stream key into public scripts, shared screenshots or logs. If the station needs to hear or inspect output locally, make that a controlled test path rather than exposing credentials or private feeds. For other software choices around a YouTube loop, see the free software overview for India, while checking whether each tool fits this audio-first workflow.
Add a visual component
YouTube Live is a video destination, so an audio-only station still needs a visual stream. A simple static image with the station name, language and programme information can be enough for a first test. Use an image the station owns or is permitted to use, and make text legible on a phone-sized screen. Avoid adding a visual production system unless there is a real editorial reason for it.
A still image can be combined with the audio output using the video encoding path available in your chosen workflow. Liquidsoap’s documented example uses FFmpeg encoding for YouTube Live, but the exact configuration depends on the installed versions and how you supply the image. Follow current tool documentation rather than assuming that a configuration written for another release will work unchanged. Test that the image remains present while audio continues, and check that the stream does not silently turn into a black frame when a source changes.
If you want moving elements such as a clock, scrolling headlines or a waveform, count that as extra workload and extra failure surface. Keep the design modest and test CPU use over a representative period. A locally generated animation may be sensible for a station with a reason to show current information; it is unnecessary if a clear still image does the job. Do not add video resolution or frame-rate detail merely because a sample configuration uses it: pick settings your VPS can encode and YouTube accepts, then test them.
The visual is also part of the listener’s expectation. Make it clear whether the station is broadcasting live from a studio or playing scheduled programming. A still graphic should not imply a live presenter when there is none. This is a small editorial decision, but it prevents a technical placeholder from misleading viewers about what they are hearing.
Configure YouTube ingestion and the stream key
In YouTube Live Control Room, create or select the stream for the station and obtain the current ingestion address and stream key shown there. Put those values into the encoder configuration that Liquidsoap and its encoding path will use. The address and key are a pair: using an old address, the wrong key or a key from another stream can prevent the broadcast from reaching the intended event. Do not copy credentials from an unrelated tutorial or another channel.
Treat the stream key as a password. Restrict access to configuration files, avoid publishing command lines that contain it, and redact it from support messages and diagnostic captures. If it is exposed, replace or reset it through the channel’s current control-room options and update the encoder. A key does not establish permission to use the audio, and having permission does not remove the need to configure the correct YouTube destination.
Follow YouTube’s current encoder guidance for accepted protocols and settings. Its general guidance lists constant bitrate encoding, AAC or MP3 audio, and a recommended two-second keyframe interval, with no more than four seconds (YouTube encoder settings). These are platform recommendations, not a promise that a particular VPS or configuration will perform well. Check the live documentation before deployment because platform guidance can change.
For a first deployment, create a private or unlisted test where that suits the channel and its audience. Confirm that YouTube receives the expected title and visual, that audio is present, and that speech and music remain in sync. Test the actual path from the VPS rather than only previewing local files. Keep a second person able to check the public-facing result if the stream is important to listeners.
Prefer RTMPS where supported
YouTube recommends RTMPS when the encoder supports it. In the Live Control Room, obtain the RTMPS ingestion URL and use it with the stream key; YouTube describes this setup in its RTMPS instructions. Confirm that the encoder path you are using supports the protocol and that the address is the RTMPS address displayed for the stream, not a remembered value from an older setup.
RTMPS protects the connection in transit compared with an unencrypted RTMP connection. It does not change the rights status of the programme, validate the stream key, or guarantee that a network route will remain available. If RTMPS is not supported in the installed encoding path, check current Liquidsoap and FFmpeg documentation for a supported configuration before switching protocols; avoid quietly falling back without understanding the security and platform implications.
Use the protocol choice consistently in your configuration and in the test. When troubleshooting a failed connection, first verify the current URL and key, the selected protocol, and whether outbound access from the VPS is available. Keep the credential private while checking logs, and do not paste a full connection string into a public issue or forum.
Test and monitor stream health
A broadcast that starts successfully is not yet a tested 24/7 channel. Test the intended source, visual and destination together for long enough to encounter the kinds of changes the station expects: programme transitions, source reconnections, playlist boundaries or a studio handover. Listen to the YouTube output itself, not only the input, and check that audio stays present and in sync. YouTube’s encoder guidance also recommends testing representative audio and movement and monitoring stream health; use the Live Control Room indicators as one signal, not the whole monitoring plan.
Watch the VPS process and system load during the same test. If CPU stays heavily occupied or memory grows unexpectedly, simplify the visual, revisit the encoder configuration or resize based on measured workload. If the source drops, confirm that the configured fallback behaves as intended and that recovery does not leave the encoder sending silence indefinitely. Avoid assuming that a process restart alone restores the stream; verify the output returns in the Live Control Room and on the channel’s viewing page.
Plan how you will know about a problem while no one is watching. At minimum, decide who receives an alert, how they can inspect the process and stream status, and what steps restore service. A systemd restart guide is relevant if you manage the Linux service yourself, but automatic process restarts do not prove that audio is being received or that YouTube is still getting a valid broadcast. Pair recovery with checks that detect silent input and missing output.
If the station wants to serve direct audio listeners as well, treat that as a separate output with its own capacity and monitoring. Liquidsoap’s Icecast documentation describes encoding and sending audio to Icecast, which can relay it to listeners through mount points (Liquidsoap Icecast documentation). Icecast is optional for YouTube delivery; it is not a required intermediary in the Liquidsoap-to-YouTube example. Make sure the station has a reason to add it and assess the additional traffic and maintenance it brings.
Keep a short runbook with the source location, service restart procedure, key rotation steps, contact person and current configuration backup. Do not include the stream key in a version-controlled public repository. A clear runbook matters when the person who built the stream is away and the programme is due to continue. Before relying on the setup, repeat a controlled test after material changes to the operating system, Liquidsoap, FFmpeg, source feed or visual output.
The choices in this guide are easier to make once the station knows its input, rights and workload.
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 a regional radio station’s YouTube stream from a low-cost VPS?
Possibly, but “low-cost” does not identify the right plan. The source, encoding workload, traffic terms, region and recovery expectations determine what to test. Start with the smallest plan you can evaluate responsibly, measure the real workload, and do not rely on it for an unattended broadcast until the full path has been tested.
Does Liquidsoap need Icecast to send audio to YouTube?
No. Liquidsoap’s official overview includes a YouTube Live RTMP output example, so Icecast is not a required step in that path. Icecast can be useful as a separate listener-facing output if the station wants a direct audio player, but that adds its own service and traffic considerations.
Can I rebroadcast the station’s existing online stream?
Only if the station has permission for that specific retransmission and the relevant rights for the material and territories involved. A stream being publicly accessible does not establish permission. YouTube may still interrupt a live stream after a content match, so check current platform guidance and ask rights owners about Content ID allowlisting where applicable.
Should I use RTMPS rather than RTMP?
Prefer RTMPS when the encoder supports it and use the current RTMPS URL from the Live Control Room with the matching stream key. Test the connection and keep the key private. Protocol choice does not guarantee availability or settle content rights.