Music Assistant

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) runs Music Assistant comfortably for a personal library. Choose a VM with more memory if you connect many providers, scan a large local library, or want optional features such as Smart Fades that ask for more RAM.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp, so your browser can reach Music Assistant. Also allow 443/tcp once you terminate TLS on the VM.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Music Assistant by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:music-assistant-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name music-assistant \
  --image sac1647283583153:music-assistant-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open port 80 so that your browser can reach Music Assistant:

az vm open-port --resource-group <your-rg> --name music-assistant --port 80

Step 3 - Confirm the services are running

SSH in as azureuser. First boot pulls no images, because the container image is already in the image, and it completes in well under a minute. Once it completes, nginx binds port 80 and Music Assistant is ready.

systemctl is-active docker music-assistant

ss -tlnp 2>/dev/null | grep ':80 ' | head -1 | sed 's/ */ /g' | cut -d' ' -f1-4

Confirm the container is up and which version is running:

sudo docker compose -f /opt/music-assistant/docker-compose.yml ps --format 'table {{.Service}}\t{{.Image}}\t{{.Status}}'

If port 80 is not bound, first boot has not completed. This behaviour is deliberate and fails closed: Music Assistant is never published before it has been provisioned and secured. Check progress with systemctl status music-assistant-firstboot.service and journalctl -u music-assistant-firstboot.service.

Step 4 - Retrieve this VM's administrator credentials

Every VM creates its own administrator on first boot. First boot writes the username, the password and the sign-in address to a root-only credentials file. Read the file with sudo:

sudo cat /root/music-assistant-credentials.txt

Because a real administrator now exists, Music Assistant's unauthenticated first-time setup is closed. A second setup attempt is refused, so no one who reaches the instance after first boot can create an admin. Try it:

curl -s -o /dev/null -w 'second POST /setup -> HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' -d '{"username":"intruder","password":"attacker-password-123"}' http://127.0.0.1/setup

An HTTP 400 (setup already completed) is the expected result.

You can also prove from the command line that the generated password authenticates. Music Assistant accepts a JSON login, so the correct password is issued a token while a wrong one is rejected:

U=$(sudo grep '^musicassistant.admin.username=' /root/music-assistant-credentials.txt | cut -d= -f2-);
P=$(sudo grep '^musicassistant.admin.pass=' /root/music-assistant-credentials.txt | cut -d= -f2-); curl -s -o /dev/null -w 'correct password -> HTTP %{http_code}\n' -H 'Content-Type: application/json' -X POST -d "{\"provider_id\":\"builtin\",\"credentials\":{\"username\":\"$U\",\"password\":\"$P\"}}" http://127.0.0.1/auth/login; curl -s -o /dev/null -w 'wrong password -> HTTP %{http_code}\n' -H 'Content-Type: application/json' -X POST -d "{\"provider_id\":\"builtin\",\"credentials\":{\"username\":\"$U\",\"password\":\"WRONG-password\"}}" http://127.0.0.1/auth/login

The expected results are 200 for the correct password and 401 for the wrong one.

Step 5 - Sign in to Music Assistant

Browse to http://<vm-public-ip>/. Music Assistant opens on its sign-in screen. There is no open setup wizard, because first boot already created your administrator.

Enter the musicassistant.admin.username and musicassistant.admin.pass values from Step 4.

After your first sign-in, change the password from Settings. Add any further users deliberately, and do not leave open registration on.

Step 6 - Connect your music and get started

After you sign in, Music Assistant welcomes you and points you at the two things that make it useful: connecting your music sources and your players. The full library navigation (Discover, Search, Browse, Artists, Albums, Tracks, Playlists, Podcasts and more) is on the left, ready to fill as you add sources.

Open Settings > Music sources > Add a music source to connect a streaming service or your local files. Music Assistant ships integrations for Spotify, Tidal, Qobuz, YouTube Music, Deezer, a local filesystem provider and more. Pick one and follow its sign-in.

Streaming providers that use an OAuth sign-in redirect back to Music Assistant. If you connect one of those, first set your instance's reachable address in Settings > Core > Web server, so the redirect returns to the right place. Use your public IP or, better, a DNS name behind HTTPS. Local files and token-based providers work without this.

Step 7 - Add and control your players

Music Assistant streams to a wide range of devices. Under Settings > Players, it ships providers for AirPlay, Chromecast, DLNA, Sonos, a synchronised group player and locally attached audio out. It also includes its own built-in web player, so you can listen from the browser straight away.

Providers that discover devices on your local network (Chromecast, DLNA) show a reconfigure prompt until you point them at a network they can reach.

Step 8 - Check persistence and the image pin

The stack is enabled to return after a reboot, and the container image is pinned so that your instance is reproducible. Unattended security upgrades keep the base operating system patched. Run the following checks:

systemctl is-enabled docker nginx music-assistant-firstboot music-assistant

systemctl is-enabled unattended-upgrades

sudo docker image ls --format '{{.Repository}}:{{.Tag}}' | grep music-assistant

Step 9 - Enable HTTPS with Let's Encrypt

Put Music Assistant behind HTTPS before you expose it to the internet, so that your credentials are encrypted in transit. Point a DNS record at the VM, then install a certificate. The bundled nginx proxies to Music Assistant on the loopback interface, so certbot's nginx integration terminates TLS in front of it:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d music.example.com

After you issue the certificate, set your instance's public address in Settings > Core > Web server to the https:// host name. Make sure 443/tcp is open in the NSG, and reconnect any OAuth-based providers so that their redirects use the new address.

Step 10 - Back up and maintain your VM

Music Assistant stores its user accounts, library, provider configuration and settings under /opt/music-assistant/data, so archiving that directory is a complete backup:

sudo systemctl stop music-assistant
sudo tar czf music-assistant-data-backup.tar.gz -C /opt/music-assistant data
sudo systemctl start music-assistant

Store the backup somewhere safe. Unattended security upgrades keep the operating system patched, and Azure Backup or managed disk snapshots give you whole-VM recovery.

Security notes

• No shared secret ships in the image. The image contains no users and no secrets. The first boot of your VM generates the administrator account.
• The first setup cannot claim your instance. Music Assistant's unauthenticated first-time setup creates the administrator. First boot creates a real administrator before the app is reachable, and a second setup attempt is then refused, so no passer-by can register the admin account.
• Nothing is published before it is secured. In the shipped image, nothing is bound to port 80. First boot enables the public site only after it has provisioned and secured Music Assistant, so an unprovisioned instance is never exposed to the network.
• Fail closed. If first boot cannot complete, port 80 is never bound at all.
• Put Music Assistant behind HTTPS before real traffic, and restrict 22/tcp to your management network.
• The application is not exposed directly. The Music Assistant container binds 127.0.0.1 only, and nginx on port 80 is the sole network-facing service.

Architecture summary

Component Detail

Application Music Assistant 2.9.9 (Apache-2.0), ghcr.io/music-assistant/server:2.9.9

Orchestration Docker Compose at /opt/music-assistant, managed by music-assistant.service

Web server nginx reverse proxy on :80 to the loopback bound Music Assistant container (WebSocket aware)

Data /opt/music-assistant/data (user DB, library, provider config), in-VM only

Credentials /root/music-assistant-credentials.txt, mode 0600, root only

First boot music-assistant-firstboot.service, sentinel /var/lib/sac/data/music-assistant-firstboot.done

Ports 22/tcp SSH, 80/tcp Music Assistant interface, 443/tcp once TLS is configured

Base image Ubuntu 24.04 LTS, patched at build time, unattended security upgrades enabled

Support

SecureAnyCloud images come with 24/7 support. Email sales@secureanycloud.com with your Azure subscription ID and the VM name. For questions about Music Assistant itself, see the Music Assistant project and its documentation.

Deploy on Azure

Launch Music Assistant on Ubuntu 24.04 LTS with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com