selfhosted-music-overview: a comparison table for self-hosted music servers and clients

What problem a music server comparison table actually solves

Choosing a self-hosted music server is a decision made under incomplete information. The projects look similar from their landing pages: most speak the Subsonic API, most support multiple users, most can scrobble to last.fm. The differences that matter surface later, after you have imported a library and pointed a client at it. Does the server write tags back to your files, or only read them? Can it transcode on the fly for a phone on a slow connection? Does it expose DLNA so a television or an amplifier can see the library without a separate app?

This repository exists to answer those questions in one place. It is a table, not software. The README describes its intent plainly: to "provide an overview of self-hostable music streaming servers and clients." The audience is someone standing at the fork, comparing Airsonic, Airsonic-advanced, gonic and Ampache, and trying to work out which one fits a specific setup. The table is organized in two halves, a Server Overview and a Client Overview, with an Emoji Definitions section explaining the symbols used in the cells.

How the server matrix is structured

The Server Overview is a wide table. Each row is a project, and each column is a capability. The columns visible in the README cover Scrobbling, Jukebox Mode, Read Tags, Write Tags, API, Share Music, Multi-User, Multi-Library, Smart Playlists, Heart/Favorites, 5 Star Rating, Replay Gain, Transcode, DLNA, Multi-Room, Lyrics, free, Demo, Source Code, License and Reviewed Version.

Cells are filled with emoji rather than prose. A heavy check mark means supported, a cross means not supported, and a grey question mark means the state is unknown or unverified. The Emoji Definitions section is where those symbols are defined, which matters because the table is unreadable without it. Some cells carry a heavy dollar sign alongside a check mark, which the table uses to flag a paid tier or a paid component. Footnotes are attached to specific cells: gonic's Smart Playlists and Multi-Room entries both carry a footnote reference tagged gonic-recipies, pointing down to the Footnotes section.

The API column is the most consequential one for interoperability. It records which protocol a server exposes, and the values are Subsonic, OpenSubsonic, or a combination such as Subsonic plus a custom API. That column is what determines whether the client you already use will talk to the server at all.

Reading the rows: what Airsonic, gonic and Ampache differ on

The table is more useful when read across rows than down columns. Airsonic and Airsonic-advanced are near-identical in the visible columns: both list last.fm for scrobbling, both check Read Tags and Write Tags, both expose the Subsonic API, both support Multi-User and Multi-Library, and both are GPLv3. The differences that show up are in Transcode and licensing flags. Airsonic's DLNA cell carries both a check mark and a dollar sign, while Airsonic-advanced's carries only a check mark. Airsonic's free column also carries the dollar sign, meaning part of it is paid; Airsonic-advanced's does not. The Reviewed Version column records 10.6.2 for Airsonic and 11 for Airsonic-advanced.

gonic diverges sharply. It scrobbles to last.fm and ListenBrainz, supports Jukebox Mode, reads tags but does not write them, exposes OpenSubsonic rather than the older Subsonic API, and supports Smart Playlists, 5 Star Rating, Replay Gain, Transcode and Multi-Room. Its Demo column is a cross, so there is no hosted instance to try. Ampache is the broadest entry in the visible rows: it scrobbles to last.fm, ListenBrainz and libre.fm, checks Write Tags, Share Music, Multi-User, Multi-Library, Smart Playlists, Heart/Favorites, 5 Star Rating, Replay Gain, Transcode and DLNA, and exposes both the Subsonic API and a custom API. The trade-off is visible in the same row: a wider feature surface generally means more configuration and more moving parts to maintain.

Getting the table onto your machine

There is nothing to install. The repository is a README, and the material supplied does not include a package manifest, a build step or a hosted site. The practical way to use it is to clone the repository and read the README locally, or to read it in the browser on the default branch, which is main. A clone looks like this:

git clone https://github.com/basings/selfhosted-music-overview

There are no config keys, no environment variables and no service to start. If you want to render the tables as something other than raw markdown, any markdown viewer will do, but the repository itself does not ship one. The README's own Table of Contents links to Server Overview, Client Overview, Emoji Definitions, How to Contribute (WIP), Noteworthy, Selfhosted Photos and Footnotes. The How to Contribute section is marked WIP, which is worth noting before you plan a pull request: the contribution process is not yet documented in the material provided.

Where the table is thin

The most obvious limitation is that the table records capability, not quality. A check mark in the Transcode column says the feature exists; it says nothing about how well it performs, which codecs are supported, or how much CPU it consumes. For a server running on a small ARM board, that distinction decides whether the feature is usable at all.

The second limitation is staleness. The Reviewed Version column pins each row to a specific release, and those numbers are snapshots. Airsonic is recorded at 10.6.2 and Airsonic-advanced at 11. A project that has since added Write Tags or dropped DLNA will not be reflected until someone updates the row. The grey question mark cells compound this: they mark unknowns rather than absences, so a reader cannot tell whether a feature is missing or merely untested. Jukebox Mode is a grey question mark for both Airsonic rows and for Ampache, which is exactly the kind of cell a reader is most likely to misread as a no.

The third limitation is scope. This is a music-specific table. If your library is mixed media, or if you are weighing a general media server against a dedicated music server, this repository will not help you make that comparison. It also does not cover deployment, backup or migration between servers, which is where most of the real work lives.

A real alternative: Awesome Selfhosted

The closest thing to an alternative is the broader awesome-selfhosted list, which catalogs self-hosted software across categories including media streaming. The difference in approach is structural. Awesome Selfhosted is an index: it tells you that a project exists, links to it, and moves on. It does not carry a feature matrix, so it cannot tell you that gonic reads tags but does not write them, or that Airsonic-advanced exposes the Subsonic API while gonic exposes OpenSubsonic.

That difference cuts both ways. Awesome Selfhosted stays current because adding a link is cheap, while this table requires someone to verify each cell against a release. The narrower scope here is what makes the columns possible: because the subject is only music servers and clients, the table can afford to track Replay Gain and Multi-Room, which a general index would never carry. If you already know which projects exist and need to choose between them, this table is the more useful artifact. If you are still surveying the space, it is not.

Licence, maintenance and what the project costs to keep

The repository's README opens with a link to the GNU Free Documentation License version 1.3, which is the licence the content is published under. The repository metadata reports the licence as NOASSERTION, meaning GitHub could not match a recognized licence identifier from the files present. The README's own link points at FDL-1.3, so that is the licence to read if you intend to reuse the table. This is a note about what the files say, not legal advice; if you plan to republish the table, read the licence text yourself.

Maintenance cost is where the design has a real weakness. A feature matrix is only as good as its last update, and every cell is a claim about a specific version of a specific project. The Reviewed Version column makes that explicit, which is honest, but it also means the table decays with each upstream release. For a reader, the practical implication is that the table is a starting point for a shortlist, not a source of truth. For a contributor, the cost of a useful change is not adding a row but re-verifying the cells in it against a current release.

The client half of the table is present in the Table of Contents as a Client Overview section, but the material supplied does not include its contents. A reader who needs to know which clients support OpenSubsonic versus the older Subsonic API will have to open the repository directly.

Editorial conclusion

Use this table if you are choosing a self-hosted music server and want to compare Subsonic API compatibility, tag writing, transcoding and DLNA support before installing anything. Skip it if you need deployment instructions or performance data, since it provides neither. Verify the Reviewed Version column against each project's current release, because the table's entries are pinned to specific versions and will age.

Official sources

1. basings/selfhosted-music-overview on GitHub
2. Issues
3. README