Airsonic-Advanced

Last reviewed Sep 13, 2026 · 785 words

The honest case for Airsonic-Advanced in 2026 is that you already run it, or that you need one of three features Navidrome still lacks: podcast subscriptions, per-user upload and folder permissions, and a jukebox mode that plays through the server's own sound card. If none of those apply, the 512 MB JVM footprint and the slow release cadence make Navidrome the safer pick for a new music server, and I would start there.

Four forks deep, and it shows in both directions

Airsonic-Advanced is a fork of Airsonic, which forked Libresonic, which forked Subsonic when Subsonic went proprietary in 2016. Twenty years of accumulated features ride along: Subsonic API compatibility that every mobile client on earth already speaks, multi-user accounts with per-folder access, transcoding profiles per player, podcasts, internet radio, playlists shared between users, and last.fm scrobbling. The fork exists because Airsonic proper stalled, and Airsonic-Advanced brought a modern Spring Boot base, WebSocket-driven UI updates, and a newer web player.

The other direction is that the project sits around 1,400 stars and moves slowly. Releases are irregular, and the GitHub issue tracker is where most support happens. It works, it is stable, and it is not where the energy in self-hosted music is any more.

Where it still beats the lighter servers

Navidrome and Gonic are single-binary Go servers that start in a second and idle around 50 MB. Airsonic-Advanced beats them on breadth:

• Podcasts: subscribe, auto-download, and stream episodes from the same client you use for music. Navidrome does not do this.
• Per-user rights: which users may upload, which may see which music folders, who may create shared playlists, who may use the jukebox. Family setups with a "kids" folder are trivial.
• Jukebox mode: the server plays audio through its own output, useful if the box is wired to the living-room amplifier.
• Transcoding rules per player and per user, so a phone on mobile data gets 128 kbps Opus while the desktop gets lossless.

If you need two of those four, the JVM cost is justified.

The JVM cost is real but bounded

The catalogue's 512 MB minimum is honest. In practice the container idles around 400 to 600 MB with a 30,000-track library and spikes during a scan. Startup takes 20 to 40 seconds on a small ARM board, which matters if you restart often and does not matter otherwise. Scans of a large library take minutes rather than seconds. On a NAS with 4 GB or more this is invisible; on a 1 GB Raspberry Pi it is the only thing running.

A compose file that survives updates

services:
  airsonic:
    image: airsonicadvanced/airsonic-advanced:latest
    ports:
      - "4040:4040"
    environment:
      - JAVA_OPTS=-Xmx700m
    volumes:
      - ./data:/var/airsonic
      - /srv/music:/var/music:ro
      - ./playlists:/var/playlists
      - ./podcasts:/var/podcasts
    restart: unless-stopped

Two details matter. First, mount music read-only unless you use the upload feature; a bug or a misclick in a media server should never be able to delete your FLAC collection. Second, /var/airsonic holds the embedded database, settings, and the transcoding cache, so that directory is the backup target, and it is small enough to include in a nightly tarball. Put it behind Caddy for TLS before pointing a phone at it; the Subsonic API sends the password (or a salted token) in the query string, and that should not travel over plain HTTP.

Clients are the reason this lineage refuses to die

Anything that speaks Subsonic works: Symfonium and Ultrasonic on Android, play:Sub and Substreamer on iOS, Sonixd and Feishin on desktop, plus the built-in web player. This is the same client pool Navidrome relies on, so switching between servers later costs you a scan and nothing else. That portability is the strongest argument for the whole Subsonic ecosystem over Plex-style closed apps, and it is why the Spotify replacement question usually ends with one of these servers rather than a streaming-service clone.

What I'd do

Existing Airsonic or Airsonic-Advanced user with podcasts or per-user folders in daily use: stay, pin the image tag, back up /var/airsonic nightly, and give the container a 700 MB heap cap so a scan cannot starve the host. Everyone else building a music server from scratch: run Navidrome, which does the core job on a tenth of the memory with a far busier development team, and revisit Airsonic-Advanced only if you discover you need the jukebox or podcast features. The two servers share every client, so trying the wrong one first costs you an afternoon at most.