AzuraCast: Self-Hosted Radio Management via Docker Compose

The problem AzuraCast solves for station operators

Running an internet radio station by hand means assembling several unrelated programs. You need a streaming server, a playout engine that schedules tracks and inserts live input, a database, and some way for non-technical staff to upload media and change the schedule. AzuraCast's README describes the project as an Internet radio station "in a box": a self-contained suite, distributed using Docker, that contains a full free and open-source web radio software stack plus a web interface and a documented API to manage stations. The audience is the operator who wants the whole stack rather than the individual parts. The README states plainly that installation assumes a basic understanding of the Linux shell terminal, but that once installed, every aspect of the station is managed through the web interface. That split matters: the setup is a systems task, the daily work is not.

How the Docker stack is assembled

The Dockerfile shows the composition directly. It pulls MariaDB from the mariadb:lts-noble image, an Icecast build from ghcr.io/azuracast/icecast-ac, and a prebuilt copy of the project's own documentation site, then assembles them into a final image based on php:8.5-fpm-trixie. A PHP extension installer stage handles the extension set. The repository layout confirms the split between backend/ and frontend/, and package.json shows the frontend is Vue 3 with Vite, Pinia, vue-router and a set of libraries for calendars, charts, maps and audio waveform display. The topics list names Icecast, Liquidsoap and Shoutcast alongside station and streaming. So the architecture is a PHP application server that owns configuration and state, a MariaDB instance for persistence, and Icecast as the listener-facing streaming server, with Liquidsoap as the automation layer. The web app is the control surface over all of it.

Installing AzuraCast and reaching the web interface

The README does not inline installation commands. It points to the installation guide at azuracast.com/docs/getting-started/installation/ and says to follow that guide for installing on your own server. The repository does ship a docker.sh script and a docker-compose.sample.yml, and the Makefile exposes the developer path, which is useful for understanding the shape of a deployment even if you follow the official guide instead.

For a development checkout, the Makefile defines install as a call into the shell script:

make install

That target runs bash ./docker.sh install-dev, so it is the developer-mode installation rather than the production path. The Makefile also wraps the ordinary Compose lifecycle:

docker compose up -d
docker compose down

up starts the stack detached and down stops it. The restart target is defined as down followed by up. After a branch update, update rebuilds the containers and then runs the post-update target, which stops the stack, runs azuracast_dev_install --update inside the web container, and starts it again. The sample environment file in the repository root is azuracast.sample.env, which is where you would look for the configuration keys a deployment expects. The README does not state which port the web interface is published on, so read the sample Compose file and the installation guide rather than guessing.

The demo instance and what it tells you before you install

The README offers a live demo at demo.azuracast.com with the username [email protected] and password demo. That is the cheapest way to judge whether the interface fits how your station actually works, and it costs nothing. It is also the only way to evaluate the parts of the product the README describes in prose only, such as the API and the media management screens. Two caveats. The demo is a shared instance, so it says nothing about how the stack behaves under your listener load or on your hardware. And a demo login is not a substitute for reading the system requirements, which the README links separately at azuracast.com/docs/getting-started/requirements/. Check those requirements against your host before you start, because the Dockerfile targets PHP 8.5 on a Trixie base, and that is a recent runtime.

Where AzuraCast is the wrong tool

If you want a single Icecast process and a config file, AzuraCast is far more machinery than the job needs. It brings a database, a PHP application, a queue of background services and a container orchestration layer, all of which you then have to keep running. The README's own framing supports this: it assumes shell familiarity and directs you to a separate installation guide, which is not the shape of a five-minute setup. There is also a hard operational boundary. The suite manages Icecast, Liquidsoap, MariaDB and the application itself, so it needs meaningful control over the host's Docker daemon. On shared hosting or any environment where you cannot run containers with that level of access, the project's own distribution model does not apply. The repository does carry a KNOWN-ISSUES.md file at the top level, which is worth reading before you file anything: it exists precisely because some behaviours are known and documented rather than fixed.

AzuraCast compared with running Icecast directly, and with LibreTime

The honest comparison is with the components AzuraCast bundles. A bare Icecast deployment gives you a streaming server and nothing else: you write the XML configuration, you arrange the source client, and you handle scheduling and media elsewhere. That is less to maintain and less to break, and it is the right answer if your playout already exists. AzuraCast's difference is that Icecast becomes one internal part of a managed stack, with a database and a web UI in front of it. LibreTime is the other comparison people search for. Both are self-hosted radio suites, but the repository evidence here shows AzuraCast's own distribution choice: it ships as a Docker image built from a Dockerfile that pins its Icecast fork, its MariaDB base and its documentation build, and package.json shows a Vue 3 frontend. That is a specific, opinionated packaging decision rather than a general one, and it is the axis on which you should compare the two for your own environment.

Licence, maintenance and the cost of staying current

AzuraCast is licensed under the Affero GNU General Public License version 3.0, stated in the README and in package.json. The AGPL's network clause is the part that matters for a hosted service: if you modify the software and let users interact with it over a network, the licence's terms attach to that distribution. That is a description of the licence text, not legal advice, and anyone running a commercial or white-labelled service should read LICENSE.md and take their own advice. On maintenance, the last push to the default branch was on 2026-09-21, two days before this writing, so the repository is receiving current work. The release list is a different signal: the most recent tagged release shown is 0.19.0 from 2023-08-17, with 0.18.1 and 0.18.0 before it in April 2023. If you deploy from tagged releases rather than the main branch, you are running code that predates years of commits. The README also states that the project is built and maintained by volunteers, so support responses may be delayed, and that issue reports require server log files to be actionable. Budget for the upgrade path accordingly: the update.sh script and the Makefile's update target both exist, but the README does not document rollback, so plan your own backups before upgrading a live station.

Editorial conclusion

Adopt AzuraCast if you want a complete station stack with a web interface and you are comfortable running Docker on a Linux host. Do not adopt it if you only need a bare Icecast or Liquidsoap process you configure by hand, or if you cannot give the containers root-level Docker access. Before committing, read the System Requirements and Installation pages under azuracast.com/docs, check whether your host meets them, and confirm how you will reach the web interface on its published port.

Frequently asked questions

Official sources

1. AzuraCast/AzuraCast on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases