Self-host Music Assistant on Netcup — multi-room audio without the cloud
TL;DR: Running Music Assistant on Netcup in 5 minutes
Self-host Music Assistant on a Netcup VPS and you get a single library that fuses Spotify, Tidal, Qobuz, YouTube Music and your local FLAC collection, then pushes audio to anything that speaks AirPlay, Chromecast, Sonos or Snapcast. Music Assistant is the open-source multi-room audio brain that most people first meet as a Home Assistant add-on — but it runs perfectly well standalone on a small server.
- What it is: a Python media-library manager and player controller, not a streaming service of its own.
- What it replaces: the patchwork of vendor apps (Sonos S2, AirPlay, Spotify Connect) with one queue across all of them.
- Providers: Spotify, Tidal, Apple Music, YouTube Music, Qobuz, Deezer, plus local files, Plex, Jellyfin and Subsonic.
- Players: 24+ protocols — AirPlay, Google Cast, Snapcast, DLNA, Sonos, WiiM, Squeezelite, MPD.
- Footprint: ~2 GB RAM minimum, 4 GB+ recommended; light CPU until you run Smart Fades or many Snapcast streams.
- License: Apache-2.0, maintained by the Open Home Foundation.
The catch — and read this before you provision — is that Music Assistant discovers and controls players over mDNS on the same Layer 2 network. A bare VPS is not on your living-room LAN, so the standard fix is a Layer 2 overlay (ZeroTier bridged to your home network) that puts the server and your speakers in one broadcast domain. The Quick Start below covers exactly that.
docker run -d --name music-assistant --network host \
--cap-add=SYS_ADMIN --cap-add=DAC_READ_SEARCH \
--security-opt apparmor:unconfined \
-v /opt/music-assistant/data:/data \
ghcr.io/music-assistant/server:latest
Primary pick: VPS 1000 G12 — 4 vCPU, 8 GB RAM, 256 GB NVMe, around €10.37/month.
- First month free:
5799nc17815136861 - Second code:
5799nc17774618550 - Third code:
5799nc17815136860
Introduction
Multi-room audio is a graveyard of walled gardens. Sonos won't talk to your AirPlay speakers, your Chromecast pucks ignore both, and the one Qobuz subscription you actually pay for can only be cast from the official app on the device that happens to have it installed. Music Assistant exists to collapse that mess into a single queue: one library, every provider, every speaker, controlled from one web UI or from Home Assistant.
Most people run it on a Raspberry Pi sitting next to the router, and for a pure home setup that is the correct answer. You self-host on a Netcup VPS instead when you want the library brain to be always-on and decoupled from the hardware you keep rebooting — when your Home Assistant box is also doing too much, when you want the streaming-provider aggregation and metadata cache to live somewhere with real NVMe and a stable uptime, or when you are running Snapcast to push synchronized audio to clients that connect outbound from several locations. Netcup fits because it is cheap, the hardware is owned (not resold), the data centers sit in Germany and Austria under EU jurisdiction, and every tier is NVMe-backed.
This is not a drop-in cloud replacement, and the article is honest about that. Music Assistant was built for a flat home LAN, so hosting it remotely means dealing with network discovery deliberately rather than pretending it just works. By the end you will have a hardened VPS, Music Assistant running in Docker, a Layer 2 overlay so your players are actually reachable, and a clear view of which Netcup tier matches your library size and how many simultaneous streams you push.
What is Music Assistant?
Music Assistant is a self-hosted media library manager and player controller. In one sentence: it indexes the music you can access — across streaming subscriptions and local files — into a unified library, and plays any of it to any networked speaker, keeping a single shared queue across all of them. It is a self-hosted music server in the sense of orchestration, not storage; it does not host a streaming catalogue of its own, it federates the ones you already pay for.
It is a strong Sonos and Spotify Connect alternative for anyone who resents being locked into one vendor's app per speaker brand.
Architecture
The server is written in Python and ships as a Docker container, ghcr.io/music-assistant/server. The web interface listens on TCP 8095; a separate built-in stream server listens on TCP 8097 (configurable) and is what actually serves audio to players that pull a URL. State — your library index, provider config, player settings — lives under /data, which you mount as a volume. There is no external database to run; Music Assistant manages its own embedded storage inside that directory, which keeps the operational surface small.
Two networking facts define everything about deploying it:
- It relies on mDNS and uPnP discovery to find players, and expects to be on the same Layer 2 network as them. That is why the Docker image runs with
--network host. - It needs a couple of elevated capabilities (
SYS_ADMIN,DAC_READ_SEARCH) and an unconfined AppArmor profile to mount network shares and discover devices cleanly.
Who maintains it
Music Assistant is an open-source project under the Open Home Foundation, the same non-profit umbrella behind Home Assistant and ESPHome. The license is Apache-2.0 — permissive, no copyleft, no source-available rug-pull risk. Releases are frequent; the current line at the time of writing is 2.9.x (2.9.1 landed on 14 June 2026), with hundreds of releases behind it, so the cadence is brisk and upgrades are routine rather than rare events.
How big does the data get
Modest. The /data directory holds metadata, artwork cache and your configuration, not the music itself when you stream from providers — that stays remote. If you point Music Assistant at a local file library you mount that read-only from wherever it lives; the index of it is small. A 256 GB NVMe tier is plenty unless you intend to store the actual audio files on the VPS, which is its own bandwidth-and-cost decision discussed later.
How to use Music Assistant
Core concepts
Four nouns carry the whole model:
- Providers — the sources. A music provider is Spotify, Tidal, Qobuz, a local folder, a Plex server. A player provider is a protocol stack: AirPlay, Google Cast, Snapcast, Sonos. You enable the ones you use and ignore the other twenty.
- Players — the actual speakers. Music Assistant continuously discovers them via the enabled player providers. A device that speaks more than one protocol (a WiiM that does both AirPlay and Cast) collapses into one player entity with protocol chips, so you pick the path that sounds best.
- Queue — each player owns a queue, and the magic is that the queue is provider-agnostic. A Tidal track, a local FLAC and a SomaFM stream can sit in the same queue back to back.
- Groups — players synced together for true multi-room playback, including Snapcast for sample-accurate sync across rooms.
Day-to-day workflow
You open the web UI on port 8095, search across every connected provider at once, and send a track or playlist to a player or a group. The interface is the control surface; the audio path depends on the player. Native players (AirPlay, Cast, Snapcast driven directly by Music Assistant) generally give better quality than routing the same speaker through a Home Assistant media_player entity, because Music Assistant controls the stream end to end rather than handing off.
Snapcast is the standout feature if you care about whole-home sync: it streams a single source to many clients with tight time alignment, so the kitchen and the living room don't echo. That is also the feature that turns a remote VPS deployment from "awkward" into "useful" — Snapcast clients connect outbound to the server, so they traverse a plain VPN without any multicast gymnastics.
Integrations and extensibility
The headline integration is Home Assistant: Music Assistant runs standalone, but the official HA integration exposes its players inside Home Assistant for automations, scripts and dashboards, and supports TTS announcements ducking the music. There is also a reverse provider that pulls HA's own media players into Music Assistant. If you run voice (Assist), you can ask for music by name and have it land on the right speaker. None of this is required — the server is fully usable on its own — but if you already run Home Assistant it is the reason most people adopt Music Assistant in the first place.
Backup and operational reality
Everything that matters is in /data. Back that single directory up and you can rebuild the server anywhere — your provider logins, library customisations and player settings all live there. Streaming-provider tokens refresh themselves; the local file index rebuilds on its own if lost. The one thing that is not reproducible is your manual configuration (groups, per-player tweaks, provider credentials), so a nightly tar of /data to object storage is the entire backup story.
Quick Start Guide
1. Provision the box
Sign up for the VPS 1000 G12 at netcup.com using coupon 5799nc17815136863 for one free month. Choose Debian 12 as the image and drop in your SSH public key on creation. Then SSH in and lock the box down:
# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password
systemctl reload ssh
apt update && apt -y upgrade
Music Assistant insists on --network host, which means its ports bind to the public interface. Treat the firewall as load-bearing, not optional — step 5 closes those ports off from the internet.
2. Install Docker
Install Docker from the official convenience script (the Debian-repo version lags):
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
That gives you a current Docker Engine with Compose v2 built in. Verify with docker compose version.
3. Run Music Assistant
Create the data directory and start the container. Host networking and the two capabilities are mandatory, not cargo-culted — discovery and share mounting break without them.
mkdir -p /opt/music-assistant/data
docker run -d --name music-assistant --restart unless-stopped \
--network host \
--cap-add=SYS_ADMIN --cap-add=DAC_READ_SEARCH \
--security-opt apparmor:unconfined \
-v /opt/music-assistant/data:/data \
ghcr.io/music-assistant/server:latest
The --restart unless-stopped line is what survives a reboot; without it you'll be SSH-ing in after every kernel update wondering why the music stopped. Check the logs with docker logs -f music-assistant until you see the web server come up on 8095.
4. Bridge the VPS onto your home LAN
This is the step that makes a remote Music Assistant actually find your speakers. Because discovery is mDNS-based and players expect a shared Layer 2 segment, install ZeroTier on the VPS and join a network bridged to your home LAN:
curl -s https://install.zerotier.com | bash
zerotier-cli join <YOUR_NETWORK_ID>
On the home side, run a ZeroTier client on a device that can bridge the ZeroTier interface to your physical LAN (a Raspberry Pi or your router running OpenWrt, with bridging enabled in the ZeroTier Central admin). Once bridged, mDNS and broadcast traffic cross the overlay and Music Assistant sees AirPlay, Cast and Sonos devices as if it were plugged into your switch.
# Snapcast clients (and other outbound-connecting players)
# need only a plain L3 route — no bridging required for those.
If full Layer 2 bridging is more than you want to maintain, the pragmatic alternative is to lean on Snapcast and Squeezelite players that dial out to the server: those work over an unbridged ZeroTier or WireGuard tunnel, no multicast involved.
5. Firewall it off from the public internet
Ports 8095 and 8097 are bound to the public interface by host networking. They should be reachable only over the overlay, never from the open internet:
apt -y install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
# allow the ZeroTier interface (name is usually ztXXXXXXXX)
ufw allow in on zt+ to any
ufw enable
Now the UI and stream server answer only on the overlay. Reach the web interface at http://<vps-zerotier-ip>:8095.
6. Add providers and players
In the web UI, add your music providers (log into Spotify, Tidal, Qobuz; point the File provider at a mounted directory or SMB share for local files). Enable only the player providers you own — AirPlay, Google Cast, Snapcast. Discovered speakers appear within seconds once the bridge is up. Send a track to one, then create a group and test multi-room sync.
7. Optional: front it with Caddy
If you want the UI over HTTPS with a real hostname instead of an overlay IP, put Caddy in front. Caddy fetches a Let's Encrypt cert the first time it sees an HTTPS request — no certbot, no cron, no expiry surprises.
music.example.com {
reverse_proxy 127.0.0.1:8095
}
Keep this bound to the overlay or behind authentication; the web UI has no login wall of its own by default.
Choosing the Right Netcup Server for cheap Music Assistant hosting
Music Assistant itself is light. The variables that move the needle are how many simultaneous streams you transcode, whether you run Smart Fades and Snapcast across many rooms, and whether you intend to store the actual audio files on the server rather than streaming them from providers. Here are the four tiers that bracket realistic deployments.
VPS 500 G12 — the thrifty pick for a single household
Specs: 2 vCPU, 4 GB RAM, 128 GB NVMe, traffic included. Around €5.91/month (verify on netcup.com).
Why it works for Music Assistant: 4 GB lands exactly on the recommended RAM, and for one home pushing audio to a handful of players this is enough, Smart Fades included. The 128 GB disk is fine when you stream from providers and only cache metadata. It gets tight if you store a large local FLAC library on the box or run a dozen Snapcast clients.
Coupons (each pops a different code at build time):
36nc1771801554036nc1771801554536nc17718015549
VPS 1000 G12 — recommended for most Music Assistant deployments
Specs: 4 vCPU, 8 GB RAM, 256 GB NVMe, traffic included. Around €10.37/month (verify on netcup.com).
Why it works for Music Assistant: 8 GB gives real headroom for Smart Fades, metadata caching and several concurrent transcodes without the box ever feeling pressed. The 256 GB NVMe comfortably holds a meaningful local library alongside the index. This is the tier to pick if you don't want to think about resources again.
Coupons (each pops a different code at build time):
5799nc178151368625799nc177180152615799nc17815136861
VPS 2000 G12 — large libraries and many-room Snapcast
Specs: 8 vCPU, 16 GB RAM, 512 GB NVMe, traffic included. Around €19.25/month (verify on netcup.com).
Why it works for Music Assistant: if you store a large local audio collection on the server and push synchronized Snapcast streams to many rooms with on-the-fly transcoding, the extra cores and 512 GB disk earn their keep. Overkill for a single household; sensible for a music-heavy home or a small shared setup.
Coupons (each pops a different code at build time):
5800nc177180152305800nc178151368605800nc17802654090
RS 1000 G12 — dedicated cores for sustained transcoding
Specs: 4 dedicated AMD EPYC 9645 cores, 8 GB RAM, 256 GB NVMe. Around €12.79/month (verify on netcup.com).
Why it works for Music Assistant: the VPS line's vCPUs are shared and burst-bound. If you transcode many concurrent streams or run Snapcast for several rooms continuously, sustained CPU matters and dedicated EPYC cores avoid the noisy-neighbour ceiling. Same RAM and disk as the VPS 1000 G12 for a few euros more, with predictable performance under load.
Coupons (each pops a different code at build time):
5159nc177180154435159nc177180154415997nc17809735220
| Offer | vCPU | RAM | NVMe | Approx. price |
|---|---|---|---|---|
| VPS 500 G12 | 2 | 4 GB | 128 GB | €5.91/mo |
| VPS 1000 G12 | 4 | 8 GB | 256 GB | €10.37/mo |
| VPS 2000 G12 | 8 | 16 GB | 512 GB | €19.25/mo |
| RS 1000 G12 | 4 dedicated | 8 GB | 256 GB | €12.79/mo |
Which one should you pick? If you're trying Music Assistant for the first time and streaming from providers, the VPS 500 G12 is enough and costs less than a coffee a month. If you want a set-and-forget library server for a normal household with local files and Smart Fades, the VPS 1000 G12 is the right default — buy the headroom. If you run continuous multi-room Snapcast with heavy transcoding, step up to the RS 1000 G12 for dedicated cores, or the VPS 2000 G12 if disk for a big local library matters more than guaranteed CPU.
Conclusion
You now have a repeatable path to self-host Music Assistant on a Netcup VPS: a hardened Debian box, the official Docker image with the capabilities it actually needs, a ZeroTier Layer 2 bridge so the server can see your speakers, and a firewall that keeps the discovery ports off the public internet. The recommended VPS 1000 G12 runs around €10.37/month, and with a first-month-free coupon your real cost over the first year lands near €9.50/month — for an always-on music brain that federates every provider and speaker you own.
One more nudge: 36nc17718015548 takes €5 off any order if you start on the smaller VPS 500 G12 instead.
The thing to keep an eye on after launch is the network layer, not the server. Music Assistant itself is stable and the upgrades are routine — docker pull and recreate the container. What breaks is discovery: if a speaker vanishes from the UI, the bridge or mDNS path is almost always the culprit, not Music Assistant. Verify your /data backup actually restores before you trust it, and you have a self-hosted multi-room setup that owes nothing to any single vendor's app.