AzuraCast 0.24.0 on AWS User Guide

Overview

This guide covers launching and verifying AzuraCast 0.24.0 on Ubuntu 24.04 from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened SRS Streaming Media Server & Media Servers AMIs listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. The other media and streaming products in the listing are described on the listing's guide hub.

AzuraCast is a free, self-hosted web radio management suite (AGPL-3.0). From one web interface you run internet radio stations: upload a music library, build playlists and schedules (including the grouped "clockwheel" playlists new in 0.24.0), let DJs broadcast live, take listener requests, publish podcasts, and give listeners a public player page. Broadcasting is done by Liquidsoap feeding an Icecast server, all inside AzuraCast's official container.

AzuraCast 0.24.0 (25 October 2026) also carries a set of security fixes for problems reported against 0.23.x, among them shell command injection through StereoTool and Supervisor settings, Shoutcast configuration injection by station users without broadcasting rights, webhook connectors that could be redirected to internal addresses, missing permission checks on waveform and media endpoints, and CSV formula injection in exports. Earlier fixes it includes cover password reset poisoning through X-Forwarded-Host (0.23.6) and an unauthenticated injection in API sorting (0.23.8).

What is on the image:

• AzuraCast 0.24.0 from the official upstream container image ghcr.io/azuracast/azuracast:0.24.0, pinned by digest sha256:2a4aa1e0b2fdc93170ef1dbc51ae2ea036053f0a74931692b23d0d7c072e5c06 and shipped unmodified. One container holds AzuraCast's own nginx, PHP 8.5.12, MariaDB, Valkey (Redis), Centrifugo, SFTPGo, Liquidsoap and Icecast
• Docker CE (official Docker apt repository) running the container under one systemd unit, azuracast.service
• HTTPS on port 443 from AzuraCast's own web server, with a self-signed certificate the container creates for your instance; port 80 redirects to HTTPS
• A per-instance super administrator and per-instance MariaDB passwords, generated on first boot into root-only files
• One station, cloudimg Radio, ready to receive your music and streaming through HTTPS
• azuracast-set-hostname, a helper that serves AzuraCast under your own DNS name

Default user: ubuntu · Architecture: x86_64 · Root volume: 20 GiB gp3

Security posture

• No first-visitor takeover. A new AzuraCast installation gives the super administrator account to whoever opens its setup page first. This image closes that before the network can reach it: first boot runs AzuraCast with only a loopback port, creates the super administrator with a 24-character password generated on your instance, proves that it can sign in, and only then lets azuracast.service publish ports 80 and 443. The setup wizard is closed from the first request anyone else can make, and self-hosted AzuraCast has no public sign-up.
• Fails closed. azuracast.service will not publish anything until first boot has written its ready marker, and its start guard refuses to run if the database passwords are missing, short, equal, readable by other users or AzuraCast's published sample value (azur4c457). If first boot cannot seed the administrator, the web ports simply never open.
• Per-instance secrets. The super administrator password, the MariaDB application and root passwords, the station's Icecast and DJ passwords, its internal API key, the SFTP host keys and the TLS key are all created on your instance. None is in the image, so no two instances share one.
• Only the web server faces the network. The container publishes exactly ports 80 and 443. MariaDB, Valkey, Icecast (8000), the live DJ input (harbor), Liquidsoap's control port and SFTP (2022) listen only inside the container. Listeners and the web DJ reach the station through https://<host>/listen/... on 443 (AzuraCast's "Use Web Proxy for Radio", on).
• The host name comes from configuration, never from a request. First boot reads the instance's public DNS name from EC2 instance metadata (IMDSv2) and sets it as AzuraCast's Site Base URL with Prefer Browser URL off, so links AzuraCast builds (password reset e-mails included) cannot be steered by a request. A cloudimg include in AzuraCast's nginx answers only this instance's own names (any other Host gets its connection closed), refuses client-sent X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Port headers (400), and redirects HTTP to HTTPS.
• Client address from the connection. AzuraCast's IP Address Source is set to the local connection, so a forged X-Forwarded-For header cannot change the address AzuraCast rate-limits sign-ins by or records for song requests. This was proved at build time: a sign-in carrying X-Forwarded-For: 127.0.0.1 was logged with the real peer address.
• HTTPS only. Always Use HTTPS is on, so AzuraCast's session cookie is Secure and HttpOnly. TLS 1.2 and 1.3 are offered; TLS 1.1 is refused.
• The container cannot read instance metadata. Webhooks, remote relays and remote playlists fetch addresses your station users enter, so the container is blocked from the instance metadata service (169.254.169.254 and fd00:ec2::254) by a Docker DOCKER-USER firewall rule that is in place before the container starts and survives Docker restarts. Docker and containerd themselves are blocked by systemd IPAddressDeny. AzuraCast's own Filter Local User-provided URLs is on as well.
• PHP2Shell fixed. The PHP inside the container is 8.5.12, the upstream release that fixes CVE-2026-109618 and CVE-2026-109619 (built 21 October 2026); no Debian PHP package is installed in it.
• No update phone-home. AzuraCast's update check (Show Update Announcements) is off, and the external IP AzuraCast would otherwise ask central.azuracast.com for is filled in from instance metadata at every start.
• What is public. The sign-in page, each station's public player page, its stream and the now-playing API are public by design (they are what listeners use). Everything else needs a signed-in account.
• Hardened SSH and system. SSH allows keys only, no root login and no X11 forwarding (proved with sshd -T). Core dumps are disabled for AzuraCast, Docker and containerd, and inside the container. The fwupd LVFS refresh timer is masked. The AMI is registered with ImdsSupport v2.0, so instances refuse token-less (IMDSv1) metadata requests. SSH host keys, the machine ID and Docker's engine ID are generated fresh on every instance.
• A note on the container environment. AzuraCast reads its database password from the container environment (it has no file-based option). It is visible to root on the host (docker inspect) and to processes inside the container, the same as on any AzuraCast installation.

Prerequisites

1. An AWS account and permission to launch EC2 instances
2. An EC2 key pair in the Region you launch in
3. Outbound internet access from the instance if you want AzuraCast to fetch album art, send e-mail or relay remote streams

Recommended instance type: m5.large. With one station AzuraCast uses about 0.5 GiB of memory and very little CPU; a busy station with many listeners, several stations, or audio processing needs more CPU. Music libraries live on the root volume: increase it at launch (or later) to fit your media.

Connecting to your instance

Step 1: Launch the instance

Option A: AWS Marketplace console

1. Open the cloudimg Hardened SRS Streaming Media Server & Media Servers AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose AzuraCast 0.24.0 on Ubuntu 24.04, then choose your Region.
4. Pick an instance type (m5.large recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
5. Security group: the listing's default group opens SSH (22), HTTP (80) and HTTPS (443). Restrict SSH to your own IP address. Leave 80 and 443 open to your listeners (a public radio station is usually open to the internet).
6. Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH from your management address and the web ports from anywhere, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and the VPC, subnet, key pair and CIDR with your own:

SG=$(aws ec2 create-security-group --group-name azuracast \
  --description "AzuraCast web radio" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=50,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=azuracast}]'

The block device mapping above grows the root volume to 50 GiB for a music library; leave it out to keep 20 GiB. You do not need --metadata-options: the AMI already makes IMDSv2 required. If you want the address to survive a stop and start, associate an Elastic IP.

Step 2: Connect and find your login

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes a few minutes after launch (the first start reads AzuraCast's 2.3 GB container image from the volume). It sets the name AzuraCast is served as (the instance's public DNS name when it has one), generates the secrets, seeds the super administrator over loopback, creates and starts the cloudimg Radio station, and writes /root/azuracast-credentials.txt (mode 0600, root). Only then does azuracast.service open ports 80 and 443. These are the entries in the credentials file and the database environment file (the secrets are not shown here):

sudo grep -E '^AZURACAST_(URL|ADMIN_EMAIL)=' /root/azuracast-credentials.txt
sudo grep -oE '^[A-Z_]+=' /root/azuracast-credentials.txt
sudo stat -c '%a %U:%G %n' /root/azuracast-credentials.txt /etc/azuracast/azuracast.env
sudo grep -oE '^MYSQL_[A-Z_]*PASSWORD=' /etc/azuracast/azuracast.env

AZURACAST_URL=https://ec2-3-86-31-225.compute-1.amazonaws.com/
AZURACAST_ADMIN_EMAIL=admin@azuracast.local
AZURACAST_URL=
AZURACAST_ADMIN_EMAIL=
AZURACAST_ADMIN_PASSWORD=
600 root:root /root/azuracast-credentials.txt
600 root:root /etc/azuracast/azuracast.env
MYSQL_PASSWORD=
MYSQL_ROOT_PASSWORD=

To read the values, run sudo cat /root/azuracast-credentials.txt in your own session and store them in your password manager.

Step 3: Confirm AzuraCast is running

Docker, the metadata firewall rule and AzuraCast are active, and the container runs the pinned 0.24.0 image. Only sshd and Docker's port forwarder for 80 and 443 listen beyond loopback. 2022/tcp (SFTP) and 9000/tcp appear in docker ps because the image declares them, but neither is published on the host:

systemctl is-active docker.service cloudimg-docker-imds-deny.service azuracast.service
sudo docker ps --format '{{.Names}} {{.Image}}'
sudo docker ps --format '{{.Ports}}' | tr ',' '\n' | sed 's/^ //'
sudo ss -Htlnp | awk '{print $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort -u
sudo docker exec azuracast azuracast_cli --version
sudo docker exec azuracast php -r 'echo "PHP ", PHP_VERSION, "\n";'

active
active
active
azuracast ghcr.io/azuracast/azuracast:0.24.0
0.0.0.0:80->80/tcp
[::]:80->80/tcp
2022/tcp
0.0.0.0:443->443/tcp
[::]:443->443/tcp
9000/tcp
0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("docker-proxy"))
0.0.0.0:80 users:(("docker-proxy"))
127.0.0.53%lo:53 users:(("systemd-resolve"))
127.0.0.54:53 users:(("systemd-resolve"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("docker-proxy"))
[::]:80 users:(("docker-proxy"))
AzuraCast Command Line Tools (Production) 0.24.0
PHP 8.5.12

Step 4: Prove the login and the web defaults

The sign-in page answers, the setup wizard is already complete, and the administration API refuses a signed-out request. Plain HTTP redirects to HTTPS, an unknown Host header gets no answer, a client-sent X-Forwarded-Host is refused and TLS 1.1 is not offered. The last command is the image's own round-trip check: it signs in with this instance's administrator password, proves that blank and wrong passwords are refused, and reads the station list with the session:

H=$(sed -n 's#^https://##p' /etc/azuracast/base-url)
C=(--connect-to ::127.0.0.1:)
curl -sk "${C[@]}" -o /dev/null -w 'sign-in page -> %{http_code}\n' "https://$H/login"
curl -sk "${C[@]}" -o /dev/null -w 'setup wizard -> %{http_code} %{redirect_url}\n' "https://$H/setup/register"
curl -sk "${C[@]}" -o /dev/null -w 'admin API, signed out -> %{http_code}\n' "https://$H/api/admin/stations"
curl -s "${C[@]}" -o /dev/null -w 'http -> %{http_code} %{redirect_url}\n' "http://$H/login"
curl -sk -o /dev/null -w 'unknown Host -> %{http_code}\n' -H 'Host: evil.example' https://127.0.0.1/login || true
curl -sk "${C[@]}" -o /dev/null -w 'client-sent X-Forwarded-Host -> %{http_code}\n' -H 'X-Forwarded-Host: evil.example' "https://$H/login"
curl -sk "${C[@]}" -o /dev/null -w 'TLS 1.1 -> %{http_code}\n' --tlsv1.1 --tls-max 1.1 "https://$H/login" || true
sudo /usr/local/sbin/azuracast-roundtrip.sh

sign-in page -> 200
setup wizard -> 302 https://ec2-3-86-31-225.compute-1.amazonaws.com/setup/complete
admin API, signed out -> 403
http -> 301 https://ec2-3-86-31-225.compute-1.amazonaws.com/login
unknown Host -> 000
client-sent X-Forwarded-Host -> 400
TLS 1.1 -> 000
OK round-trip https://ec2-3-86-31-225.compute-1.amazonaws.com/: login page 200; /setup/register closed; anonymous, wrong and blank password get no admin API; per-VM super administrator logs in (Secure HttpOnly session) and reads the station list; unknown Host dropped; HTTP 301 to HTTPS

--connect-to ::127.0.0.1: sends each request to this instance while keeping the real host name in the request, exactly as a browser would send it. 000 means the server closed the connection without an answer.

Step 5: Sign in to AzuraCast

Browse to AZURACAST_URL (https://<public-dns-name>/). The certificate is self-signed, so your browser warns once; accept it for this host, or set up a Let's Encrypt certificate (Step 9). Sign in with AZURACAST_ADMIN_EMAIL and AZURACAST_ADMIN_PASSWORD:

The dashboard lists your stations with their listener counts and what is playing. Open My Account (top right) first and change the e-mail address to your own and, if you like, the password; then add accounts for your team under Administration > Users (there is no public sign-up):

Step 6: Put music on the air

Open cloudimg Radio from the dashboard. Its Icecast broadcasting service and Liquidsoap AutoDJ are already running; until you add music the Now Playing panel reads Station Offline and the stream carries AzuraCast's fallback audio. Rename the station under Edit Station Settings, then:

1. Media > Music Files: upload MP3, OGG, FLAC or other audio files (or folders), then select them and add them to a playlist from the Playlists menu. Files uploaded while you view a playlist's tracks are added to that playlist directly.
2. Playlists: the station starts with a default playlist; create more playlists and schedules here. Grouped playlists (new in 0.24.0) let one "clockwheel" run several smaller playlists in a set order.
3. Overview: the station page shows the HTTPS stream address, the public player link and the state of the broadcasting and AutoDJ services, with their Restart and Stop buttons.

Listeners use the public player page or the stream address directly in any media player. Both are served over HTTPS on port 443:

H=$(sed -n 's#^https://##p' /etc/azuracast/base-url)
C=(--connect-to ::127.0.0.1:)
curl -sk "${C[@]}" "https://$H/api/nowplaying" | jq -r '.[] | "\(.station.name) | \(.station.shortcode) | \(.station.listen_url) | public page: \(.station.public_player_url)"'
sudo docker exec azuracast supervisorctl status | awk '/^station_/{print $1, $2}'
curl -sk "${C[@]}" -m 5 -o /dev/null -w 'stream -> %{http_code} %{content_type}\n' "https://$H/listen/cloudimg_radio/radio.mp3" || true
curl -sk "${C[@]}" -o /dev/null -w 'Icecast admin, no password -> %{http_code}\n' "https://$H/listen/cloudimg_radio/admin/"

cloudimg Radio | cloudimg_radio | https://ec2-3-86-31-225.compute-1.amazonaws.com/listen/cloudimg_radio/radio.mp3 | public page: https://ec2-3-86-31-225.compute-1.amazonaws.com/public/cloudimg_radio
station_1:station_1_backend RUNNING
station_1:station_1_frontend RUNNING
stream -> 200 audio/mpeg
Icecast admin, no password -> 401

The stream request stops itself after five seconds (-m 5); a stream never ends on its own. The public player page:

Step 7: Live DJs and extra stations

Web DJ. On the station overview choose Enable in the Streamers/DJs panel (or turn on Allow Streamers / DJs under Edit Station Settings > Streamers/DJs), then create DJ accounts under Streamers/DJs. DJs can broadcast from their browser with the station's Web DJ page, which works over HTTPS on 443 with no extra port.

DJ software and more stations. DJ software (butt, Mixxx, Rocket Broadcaster) connects to the station's DJ port (8005 for the first station), and stations you add get their own Icecast port (8000, 8010, 8020 and so on). Those ports are not published by default. To publish a range for your stations, add it to the ports in /etc/azuracast/compose.public.yaml, restart AzuraCast, and open the same range in your security group to the networks your DJs and listeners use:

services:
  web:
    ports:
      - "80:80"
      - "443:443"
      - "8000-8099:8000-8099"

sudo systemctl restart azuracast

SFTP uploads (port 2022) work the same way: add "2022:2022" and open the port to your own network only.

Step 8: Check the security controls

The DOCKER-USER chain drops traffic from the container to the instance metadata addresses while ordinary internet access works, and Docker, containerd and AzuraCast's unit carry IPAddressDeny. PHP inside the container is the fixed 8.5.12 build with no Debian PHP package installed, and SSH runs with the cloudimg pins:

sudo iptables -S DOCKER-USER
sudo docker exec azuracast curl -s -m 10 https://checkip.amazonaws.com/ >/dev/null && echo "container -> internet: reachable"
sudo docker exec azuracast curl -s -m 5 http://169.254.169.254/latest/meta-data/ >/dev/null || echo "container -> instance metadata: blocked (curl exit $?)"
systemctl show -p IPAddressDeny docker.service containerd.service azuracast.service
sudo docker exec azuracast sh -c 'php -v | head -1; dpkg-query -W -f="\${db:Status-Abbrev} \${Package}\n" "php*" | grep -c "^ii" || true'
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|x11forwarding) '

-N DOCKER-USER
-A DOCKER-USER -d 168.63.129.16/32 -j DROP
-A DOCKER-USER -d 169.254.169.254/32 -j DROP
container -> internet: reachable
container -> instance metadata: blocked (curl exit 28)
IPAddressDeny=169.254.169.254/32 168.63.129.16/32

IPAddressDeny=169.254.169.254/32 168.63.129.16/32

IPAddressDeny=169.254.169.254/32 168.63.129.16/32
PHP 8.5.12 (cli) (built: Oct 21 2026 15:49:51) (NTS)
0
permitrootlogin no
passwordauthentication no
x11forwarding no

Exit code 28 is curl's timeout: the request is dropped, not answered. The cloudimg settings are visible under Administration > System Settings: on Settings, the Site Base URL is your instance's address and Prefer Browser URL is off; on Security & Privacy, Always Use HTTPS is on, IP Address Source is the local connection and Filter Local User-provided URLs is on; on Services, Show Update Announcements is off.

Step 9: Serve AzuraCast under your own DNS name

Point a DNS record (for example radio.example.com) at the instance's public or Elastic IP address, then tell the image to serve that name. It rewrites the nginx host guard, sets AzuraCast's Site Base URL and keeps the name across reboots:

sudo azuracast-set-hostname radio.example.com

For a trusted certificate, open Administration > System Settings > Services, enter the name under LetsEncrypt > Domain Name(s) (and optionally an e-mail address) and save. AzuraCast requests the certificate over port 80 (the image leaves /.well-known/acme-challenge/ on plain HTTP for exactly this) and renews it itself. Port 80 must be reachable from the internet while it does.

Without your own name, the instance keeps following its public DNS name when it changes after a stop and start (azuracast-hostname.service updates it at boot).

Step 10: Behind a load balancer or CDN

The image is built for AzuraCast to face the network directly. A load balancer adds X-Forwarded-Proto, X-Forwarded-Port and X-Forwarded-For headers, which the host guard refuses. If you put AzuraCast behind your own load balancer: allow the load balancer's address only in the security group, remove the three X-Forwarded lines from /etc/azuracast/nginx.d/10-cloudimg-host.conf (sudo azuracast-set-hostname writes them back, so do this after any name change), reload with sudo docker exec azuracast supervisorctl signal HUP nginx, and set IP Address Source to Reverse Proxy (X-Forwarded-For) in Security & Privacy. Only do this when every request really arrives through your load balancer.

Step 11: Change passwords

• Super administrator: sign in and use My Account > Change Password. The file /root/azuracast-credentials.txt is not updated; remove the old password from it (sudo nano /root/azuracast-credentials.txt) once you have stored the new one.
• Station passwords (Icecast admin, source, relay and DJ): Edit Station Settings > Broadcasting for the station.
• The MariaDB passwords in /etc/azuracast/azuracast.env are used only inside the container and do not need changing.

Maintenance

• Operating system updates: unattended security upgrades are on. Reboot when /var/run/reboot-required exists; AzuraCast starts again by itself.
• AzuraCast updates: the image runs AzuraCast's 0.24.0 release pinned by digest, and AzuraCast's in-app updater is not used. To move to a newer release, replace the image: line in /etc/azuracast/compose.yaml with the new release tag and digest from AzuraCast's releases, then run sudo docker pull <image> and sudo systemctl restart azuracast. Take a backup first; AzuraCast runs its database migrations on start.
• Backups: Administration > Backups creates scheduled or manual backups (database, media and configuration) inside the container's backups volume; copy them off the instance or point backups at an S3 storage location. EBS snapshots of the root volume capture everything.
• Logs: sudo docker logs azuracast for the container, and Administration > System Logs in the web interface.
• What the instance contacts: AzuraCast itself contacts only what you configure (webhooks, remote relays, album art services, e-mail, Let's Encrypt). Measured on a new instance for its first boot and the following ten minutes, the only outbound lookups came from the operating system: the AWS Systems Manager agent (ssm, ec2messages), snapd (api.snapcraft.io) and package updates. Disable the SSM agent if you do not use Session Manager.

Troubleshooting

• The web page does not load right after launch: first boot is still running. sudo journalctl -u azuracast-firstboot.service -f shows its progress, and the ports open when it finishes.
• Browser shows "connection closed" for an IP address: the host guard answers only this instance's own names and addresses. Use AZURACAST_URL, or run sudo azuracast-set-hostname <name> for a new name.
• azuracast.service failed: sudo journalctl -u azuracast.service -n 50 shows the start guard's reason; sudo docker logs azuracast | tail -50 shows AzuraCast's own startup.
• A station does not play: on the station's Overview use Restart for the broadcasting service and the AutoDJ; check that Media holds files and that they are in a playlist.

Licensing

AzuraCast is licensed under the GNU Affero General Public License v3.0 or later. The image runs the official upstream container unmodified; the licence text and the written offer of source are on the instance in /usr/share/doc/azuracast/, and the complete corresponding source is at github.com/AzuraCast/AzuraCast/tree/0.24.0. cloudimg is not affiliated with, endorsed by or sponsored by the AzuraCast project.

Support

cloudimg provides 24/7 technical support for this image by email and live chat: deployment, first login, HTTPS and DNS setup, upgrades and troubleshooting. Contact support@cloudimg.co.uk.