What AzuraCast asks of the hardware
The official requirements page gives two tiers. Both assume a computer capable of running Docker, because every AzuraCast component ships in pre-built images and the installer sets up Docker and Docker Compose for you.
| Tier | CPU | Memory | Disk | The docs' own scope |
|---|---|---|---|---|
| Minimum | 64-bit x86_64 or ARM64 | 2 GB | 20 GB or more | the barest minimum, no guarantee it runs perfectly |
| Recommended | 4 cores | 4 GB | 40 GB or more | a few stations with ease; hobby use, 5 to 10 stations |
On the operating system, the docs strongly recommend Ubuntu or Debian LTS releases; Ubuntu 22.04 LTS is the newest on that list. They also ask for a fresh, minimal install without Docker already on it, and they name OpenVZ and LXC hosts as sometimes incompatible with Docker. CentOS is out because AzuraCast does not run on Podman.
Our own reading of the disk figure: 20 or 40 GB covers the system, the images and the database. Station media sits on top of that, so size the disks to your music library and its backups, not to the table.
The ports a station needs open
| Port | What uses it | Where it is set |
|---|---|---|
| 80 and 443 | The web panel and its built-in Let's Encrypt certificate; must stay on these defaults while issuing and renewing | .env, or ./docker.sh change-ports |
| 2022 | The built-in SFTP server for uploading media to local storage | AZURACAST_SFTP_PORT in .env |
| 8000-8499 | Station ports, assigned automatically as stations are created; the default exposes the first 50 stations | AUTO_ASSIGN_PORT_MIN and _MAX in azuracast.env |
Live DJs connect to the port shown on the station's info page. The docs warn that a reverse proxy placed ahead of the installation often blocks those ports, so broadcasters should be given the server's direct IP address. To run more than 50 stations, add the extra range in docker-compose.override.yml, raise the auto-assign values to match, then restart the stack from /var/azuracast with docker compose down and docker compose up -d (older installs with standalone Compose use docker-compose).
Why a whole machine suits it
Current AzuraCast releases run as a single Docker container holding the panel, its database, Liquidsoap and the broadcasting frontend. On a physical server there is no container layer underneath it to fight, which is the incompatibility the docs warn about. On a dedicated streaming server you get root on hardware nobody else uses, and the switch port is yours alone.
Listeners are the bandwidth. Each one pulls the station's bitrate for as long as they listen, so 1,000 listeners at 128 kbps is 128 Mbps leaving the box, around the clock if the station never stops. Our ports carry no transfer allowance and no overage price. By the sizing rule our streaming page uses, a fifth of the port held back, a 1 Gbps port carries about 6,250 streams of 128 kbps and a 500 Mbps port half as many. That is our arithmetic, not a figure from the AzuraCast docs.
When the stack hangs at night, rack servers and blades, and the m510 and m710x cartridges, carry an out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC) that reaches the machine when SSH does not. Reinstalling the operating system is a button in the panel.
Picking the line
- A few stations, live shows mostly: an entry line meets the recommended tier. Eight of the eighteen lines ship with 500 Mbps rather than a gigabit; check which before you order.
- A large AutoDJ library: a rack or blade line, which carries a hardware RAID controller. Moonshot cartridges have none and hold one disk on most models.
- Architecture: AzuraCast supports ARM64, but our X-Gene ARM cartridge boots only Ubuntu 16.04 and 18.04. Take an x86 line and install Ubuntu 22.04 LTS.
- City: choose the one nearest most listeners; New York, Miami, San Francisco, Amsterdam and Bucharest all sit on AS19624.
Every line is priced on the dedicated server range; a build to your own specification is on build to order. A racked machine is live about 30 minutes after the order is approved; a build to your specification is ready in 4 to 24 hours.
Installing it, with the panel fenced off
The panel asks the first browser that loads it to create the super administrator. Docker publishes ports 80 and 443 on every interface and its rules sit ahead of ufw, so ufw on its own leaves the setup page reachable. Docker's own answer is a rule in the DOCKER-USER chain; the iptables rule below covers IPv4 only. If your server has an IPv6 address, Docker also listens on 80 and 443 over IPv6, and that traffic reaches the host's INPUT chain instead, so it needs a second, temporary rule. The sequence below installs Docker with AzuraCast's own script, admits only your IPv4 address, closes 80 and 443 over IPv6, then runs the installer. Run it as root.
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-docker
# Until the admin account exists, only YOUR address reaches the containers.
# eth0 = this server's public interface (check: ip -br addr)
# 203.0.113.10 = the address you browse from
iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.10 -m conntrack --ctstate NEW -j DROP
# the rule above does not cover IPv6; close the panel ports there too
ip6tables -I INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j DROP
./docker.sh install- Answer the installer's prompts: release channel (Stable or Rolling Release) and whether to customise settings such as ports.
- From the address you allowed, open
http://plus the server's IP address and create the super administrator with a long, unique password. - Finish the initial setup the panel walks you through, including the first station.
- From another network, check that
http://[server-IPv6]/does not answer while the fence is up. Then remove both temporary rules (below): the same commands,-Dinstead of-I. Only then issue the Let's Encrypt certificate under System Settings, Services: the validation comes from addresses the rule would block, and the docs require a domain name pointed at the server.
Neither rule is saved, so a reboot also clears them. Keep the AzuraCast directory at /var/azuracast; the docs assume that path.
Backups, updates and the rest of the year
System Administration has a Backup page that schedules automatic backups, runs one now and downloads old ones; the docs say these backups do not interrupt broadcasts. From the shell, the utility script writes a .zip or .tar.gz of the database and every station; --exclude-media leaves the media out, so back that up another way.
# when done with first-run setup: lift the temporary rules
iptables -D DOCKER-USER -i eth0 ! -s 203.0.113.10 -m conntrack --ctstate NEW -j DROP
ip6tables -D INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j DROP
cd /var/azuracast
./docker.sh backup /root/azuracast-backup.tar.gz
./docker.sh backup /root/azuracast-db-only.tar.gz --exclude-media
# updating: refresh the script first, then the stack
./docker.sh update-self
./docker.sh update- Copy backup files off the machine. A backup on the same disks dies with them. Storage Locations can also point backups at an S3-compatible bucket or at Dropbox.
./docker.sh restorereplaces the current installation's data with whatever the backup holds; a backup made with--exclude-mediabrings back no media. Practise it on a spare machine.- Updating takes stations briefly off air. Back up first, pick a quiet hour, and tell listeners if it matters.
- Turn on Always Use HTTPS once the certificate works, and leave
azuracast.envpasswords alone after the database exists: the docs say changing them breaks the install.
When a managed station is the better answer
Self-hosting costs nothing in licences and everything in attention: updates, backups, certificates and the night the AutoDJ stops. If you want one station on air and no server to keep, our radio hosting plans run Icecast stations for you in New York or Bucharest, with Auto DJ on Premium and Platinum and royalty reports on every plan. How a station there is built is on Icecast hosting.
Either way, music licences are yours. The AzuraCast docs say so plainly, and our page on royalty fees covers the US collecting societies.
Questions
How much RAM does AzuraCast really need?
The documented floor is 2 GB, and the docs call it the barest minimum with no guarantee. The recommended 4 GB with 4 cores is described as enough for a few stations, aimed at hobby use of 5 to 10. CPU-heavy options such as on-the-fly ReplayGain, Stereo Tool post-processing and AutoCue raise the load; the optimizing page lists them.
Can AzuraCast share the server with an existing web server?
Not on ports 80 and 443 while it uses them itself. The troubleshooting page says another process holding those ports stops the stack from starting, and suggests moving one side; ./docker.sh change-ports moves AzuraCast. Remember that Let's Encrypt inside AzuraCast needs the default ports while it issues and renews.
How many stations fit on one install?
The docs say any number, limited by the server's resources, but only the first 50 stations' ports are exposed by default. Past that you widen the forwarded range and the auto-assign values. The optimizing page names the processor costs to watch: every mount point the AutoDJ feeds uses a small, steady amount of CPU, and audio post-processing adds more.
Is a domain name required?
Not to start: the panel answers at the bare IP. You need one for HTTPS, because Let's Encrypt certificates are issued to names, not addresses. Point a subdomain such as radio.example.com at the server before you request it.
Is it safe to run the install script as root?
The docs ask for root or sudo, and the script installs Docker from Docker's own convenience script. Read docker.sh before running it, as with any script piped from the internet. Run it on a fresh, minimal system so it does not collide with an older Docker from the distribution.