TL;DR / Summary: A community radio station needs very little compute and a predictable amount of bandwidth. Icecast on a modest VPS can serve dozens of listeners at 128 kbps, provided you size the uplink correctly, put TLS in front, and give the stream a fallback mount so silence never goes out live.
Bandwidth math before you rent
Audio streaming is bandwidth-bound, not CPU-bound. Multiply your bitrate by the number of simultaneous listeners, then add roughly ten percent for protocol overhead.
Fifty listeners at 128 kbps is about 6.4 Mbps of steady outbound traffic. That number, not the vCPU count, should drive your plan choice, and it should be measured against the provider’s guaranteed uplink rather than a burst figure.
Remember that bandwidth is billed in both directions on some hosts and only outbound on others. Ask before you commit, because a station that runs all day will use terabytes over a month.
Icecast or AzuraCast
Icecast is the bare server: a configuration file, a source password, and mount points. It is small, stable, and does exactly one job.
AzuraCast wraps Icecast in a control panel with scheduling, DJ accounts, playlists, and listener statistics. It is friendlier for a volunteer-run station but carries a full web application, a database, and more moving parts.
For a single stream with one or two presenters, plain Icecast plus a small admin script is enough. For a station with rotating volunteers and a programme grid, the panel saves hours of confusion.
Ports, TLS, and a reverse proxy
Icecast listens on 8000 by default, and many browsers now refuse mixed content on a page served over HTTPS. The clean solution is a reverse proxy such as nginx or Caddy in front of the stream.
Proxy the mount point rather than the whole admin interface, and turn off response buffering for that location. Buffering adds latency and can stall the audio when a listener’s connection wobbles.
Keep the admin interface on localhost or behind basic authentication. An exposed Icecast admin panel is a well-known target, and the default credentials are not a secret.
Mount points and a fallback stream
A mount point is the path listeners tune into, such as /stream.mp3. You can run several at different bitrates, letting slow connections pick a lower quality without a separate server.
Configure a fallback mount that plays a loop when the live source disconnects. Without it, a dropped connection sends silence or an error page, and listeners do not come back.
Name the fallback clearly in your public page. A listener who hears music instead of the scheduled show should know why, or they will assume the station has broken.
Listener limits and CPU headroom
Set a listener limit slightly below what the uplink can sustain. The failure mode you want is a polite “station full” message, not a stream that stutters for everyone because the pipe is saturated.
Transcoding is the part that eats CPU. If you offer three bitrates, you are encoding three times; on a small VPS, two is usually the sensible maximum.
Leave memory for the operating system and monitoring. A two gigabyte instance running Icecast, a reverse proxy, and a statistics collector will sit comfortably at half that, which is the headroom you want during a fundraising broadcast.
Set the public listener limit at roughly eighty percent of what the uplink can actually sustain. The last fifth exists to absorb the moment when every client reconnects at once after a network hiccup, and that burst is the difference between a brief glitch and a stream that falls over.
Metadata, now-playing, and the public page
Listeners expect a track title. Icecast accepts metadata updates from the source client, and the status endpoint exposes the current title so your page can display it without a database.
If the source is a playlist driven by a script, push the title when the track changes rather than on a timer. A title that lags one song behind is worse than no title at all, because it teaches listeners to distrust the page.
Cache the public page for a few seconds. A page that queries the stream on every request will hammer the server during a popular show, and the listener count will drop for reasons that have nothing to do with the audio.
A monitoring habit that fits a hobby station
Check two things every five minutes: whether the mount is reachable and how many listeners are connected. Icecast exposes both through its status endpoint, and a simple uptime check can read the listener count from the same response.
Watch the outbound traffic graph against your plan’s cap. A gradual climb is normal growth; a sudden step usually means a relay or a hotlink, and a quick look at the logs will name the culprit.
Finally, test the fallback once a month by stopping the source on purpose. A backup that has never been exercised is a hope, not a plan.
A station that survives a Tuesday night
Community radio does not need a large server; it needs predictable bandwidth, a proxy that speaks TLS, and a fallback that catches the moment a presenter’s laptop sleeps.
Use the VPS hosting guides to match the uplink to your listener target, then keep the configuration small enough that a volunteer can read it at midnight.
The best station infrastructure is the kind nobody talks about, because the music never stopped.
