AzuraCast

Last reviewed Sep 13, 2026 · 828 words

If you want to run an internet radio station you need a streaming server, an automated playout system that fills the air when nobody is live, a scheduler, a way for a live DJ to take over, and listener statistics. Assembled by hand that is Icecast, Liquidsoap, a cron-and-playlist arrangement, and a log parser, plus a week of your evenings. AzuraCast is those five things in one installer, and the real cost is that it wants 2 GB of RAM and, by default, the whole machine.

The installer assumes it owns the box

Installation is a script:

mkdir -p /var/azuracast && cd /var/azuracast
curl -fsSL https://raw.githubusercontent.com/AzuraCast/AzuraCast/main/docker.sh > docker.sh
chmod a+x docker.sh
./docker.sh install

It pulls a stack of containers (web, database, Redis, the streaming and playout services), binds ports 80 and 443, and opens a range of station ports starting at 8000 for the actual audio mounts. Ten minutes later you have a working admin panel with Let's Encrypt available from the settings. The friction shows up when this is not a dedicated VM: it will collide with whatever already holds 80 and 443. The fix is in /var/azuracast/.env, setting AZURACAST_HTTP_PORT and AZURACAST_HTTPS_PORT to something free and putting your usual reverse proxy in front. That is a supported path, but the project clearly expects a dedicated host, and a small VPS with 2 vCPU and 4 GB is the shape it is happiest on.

Where the RAM goes

Each station is a Liquidsoap process decoding and encoding audio continuously, plus an Icecast (or Shoutcast) instance serving it. One station with a 128 kbps MP3 mount and a 96 kbps AAC mount idles around 300 to 500 MB across the stack in my experience; the database, Redis and web containers take the rest of the first gigabyte. Three or four stations push you past 2 GB. Transcoding is the CPU cost: each mount format is a separate encode, so offering MP3, AAC and Opus triples the work. A single-station hobby setup on a 2 GB box is fine; a multi-station community outfit wants 4 GB and two real cores.

AutoDJ and scheduling are the reason to use it

Upload media through the browser or drop files via SFTP (AzuraCast runs an SFTP server per station for exactly this), tag them, build playlists, and give each playlist a weight, a schedule, or a "once per x songs" rule. Jingles, station IDs and ad breaks are just playlists with interval rules. Liquidsoap handles crossfading, replay gain and silence trimming underneath. This is the part that is painful to assemble by hand and that AzuraCast makes a form-filling exercise.

Live input works through a streamer account: a DJ points BUTT, Mixxx or the built-in Web DJ at the station's live port, and AutoDJ yields while they are connected and resumes when they drop. Listener analytics track concurrent listeners per mount with country breakdown, and the reports are enough for a community station's licensing paperwork. There is a full REST API for anything the UI does not cover, which people use to push now-playing data to websites and Discord.

Rolling versus stable, and the update habit

AzuraCast publishes a stable channel and a rolling channel; the installer defaults to stable, and I would leave it there for anything with listeners. Updates are ./docker.sh update, which also re-pulls the images, and the built-in backup (Administration, Backups, to local disk or S3) should run nightly because a station's playlists and rotation rules represent hours of work that are not stored anywhere else. Restore is ./docker.sh restore from the same directory. Test it once.

What it is not

AzuraCast is a broadcaster, not a music library. Listeners hear the same stream at the same time; nobody picks a track. If what you want is your own music collection streamed on demand to your phone, that is Navidrome, which uses a tenth of the resources and is covered in your own Spotify with Navidrome. And if your station is a single live DJ with no automation, Icecast alone on 64 MB of RAM is the honest choice; AzuraCast's weight buys playout automation, and if you will not use it you are paying for nothing.

What I'd do

For a hobby or community station: a dedicated 2 vCPU, 4 GB VPS, the stable channel, TLS via the built-in Let's Encrypt, one MP3 128 kbps mount plus one AAC mount for mobile listeners, SFTP for uploads, and nightly backups to object storage. Put Caddy or an existing proxy in front only if the host is shared, and change the .env ports before the first install rather than after. Skip it entirely for on-demand listening; that is a different product and a different category.