Meelo: A Self-Hosted Music Server Built Around Release, Track and Version Grouping

The Collector Problem Meelo Is Aiming At

Most self-hosted music servers assume one file equals one song. That assumption breaks the moment your library contains a 1998 remaster, a 2015 deluxe edition, a single with a B-side, and a live version of the same track. A flat library shows you four copies of the same song and calls it a day. Meelo's README frames the project as being designed for music collectors, and the feature list is essentially a list of the ways a flat model fails. Albums have releases, so multiple versions of one album exist but only the main version appears on browsing pages. Songs have tracks, which the README describes as roughly the same idea, so browsing does not produce duplicated songs. Songs also have versions, with a screenshot linked at assets/examples/song-groups.png. On top of that, Meelo identifies B-sides and rare tracks and surfaces them on the album and artist pages respectively. The intended user is someone who already knows which pressing they own and wants the server to reflect that rather than flatten it. If your library is a set of loose MP3s with no album or release distinction, most of this machinery has nothing to act on.

Releases, Tracks and Versions: The Data Model That Drives Everything

The distinction between an album and a release, and between a song and a track, is the architectural decision the rest of Meelo hangs off. A release is a concrete edition of an album; the album is the grouping. One release is marked as the main version and that is what appears on browsing pages, while the others remain reachable from the album page. The same pattern applies to songs and tracks, and a third layer, song versions, groups recordings that are related but distinct. This is why Meelo can show you B-sides on an album page: a B-side is a track that is related to an album without being on its main release. It is also why rare tracks can be listed on an artist page without polluting normal browsing. Two more fields ride on the same structure. Album and song types let you mark something as instrumental or a live recording, which the README presents as the way to find those categories. For compilation albums there is a filter for songs that are exclusive to the album, which prevents a compilation from claiming tracks that belong to the original records. None of this is inferred from audio. It comes from how you tag files and how Meelo parses those tags, which is the next constraint to look at.

Where the Metadata Actually Comes From

Meelo accepts metadata from two sources and lets you combine them: the embedded tags in the files, and the file names and paths. The README states plainly that the project loves embedded metadata and tells you to tag your music correctly before starting. It also warns that if you want to rely on file paths as a metadata source, you may need to be familiar with regular expressions. That warning is the honest part of the documentation. Path-based parsing is powerful but it is a regex problem, and regex problems are where a setup session turns into an afternoon. Cover art follows the same dual approach. Beyond your own tags, Meelo enriches records from external providers: the README names MusicBrainz, Genius and Wikipedia among others for genres, descriptions and ratings. Lyrics come from three places as well, embedded metadata, .lrc files, or a download, with the README mentioning synced lyrics. Scrobbling goes out to ListenBrainz and Last.fm. The practical consequence is that Meelo's browsing experience is only as good as your tags plus whatever the external providers return. A mis-tagged album will produce a wrong grouping, and the release/track model will faithfully preserve that error.

Music Videos and Format Handling

Music videos are treated as first-class citizens rather than as a separate video library. According to the README you can reach them from an album's, an artist's or a song's page, and Meelo distinguishes music videos from interviews, behind-the-scenes footage and trailers. That classification is a deliberate choice: a server that lumps all video into one bucket makes an artist's page useless. On formats, the README claims support for all formats, with a caveat worth reading closely. Transcoding is used only when the file format is not supported in the browser, and the README attributes broad format support partly to how files are parsed. So transcoding is a fallback for browser compatibility, not a general-purpose conversion pipeline. The disclaimer reinforces the intended scale: Meelo is for private use, is not intended to support heavy traffic, and the maintainers state they are not responsible for misuse. Anyone planning to expose an instance to the internet, or to serve several simultaneous streams, should read that as a design boundary rather than a legal footnote.

Getting It Running: Docker, and Then the Wiki

The README is short on installation detail by design. It states that Meelo is shipped through Docker images and directs you to the dedicated wiki at github.com/Arthi-chaud/Meelo/wiki for setup. There is no compose file, no environment variable table and no example command in the README itself, so the repository's own documentation is the only place to get the actual image name, volume layout and configuration keys. What the README does give you is the order of operations: tag your music first, decide whether metadata will come from embedded tags, file paths, or both, and only then start the server. If you intend to use path-based parsing, budget time for writing and testing regular expressions against your directory structure before the first scan. A mobile client exists for both platforms. Android builds are published as APKs on the release page, iOS is distributed through TestFlight, and the README notes that APKs and IPAs are also built on every push to main via the front-mobile workflow. Those main-branch builds are development artifacts, not releases, so the stable APK on the release page is the safer starting point.

The Cost of the Model: Tagging Debt and a Thin README

The main limitation is upstream of the software. Meelo's distinguishing features are all downstream of metadata quality, and the README says so directly by telling you to tag correctly before you begin. If your collection has inconsistent album artist fields, missing release identifiers, or no distinction between an original and a remaster, Meelo will either group things incorrectly or fail to group them at all. Fixing that means editing tags across the whole library, which is real work that no server can do for you. The second limitation is documentation surface. The README is a feature tour plus a pointer to the wiki and a link to the issue tracker for upcoming features. Configuration specifics, storage requirements and upgrade behaviour are not in the README. A third consideration is the licence. Meelo is GPL-3.0, which matters if you plan to modify it and distribute the result, and it is worth reading the licence text yourself rather than relying on a summary. Finally, the public demo the README mentions is described as still in progress, so there is no hosted instance to evaluate before you install.

How Meelo Differs From Jellyfin and Koel

The README places Meelo alongside Plex, Jellyfin, Koel and Black Candy, and says it works similarly but focuses on flexibility, browsing and listening. The meaningful difference is the data model. Jellyfin is a general media server that handles music, film and television through one library abstraction; music is one category among several. Meelo is music-first and adds release, track and version layers that Jellyfin's model does not express in the same way, along with B-side and rare-track detection and music video classification. Koel is closer in scope, being a music-focused server, but the README does not describe it as modelling multiple releases per album or grouping song versions. The trade-off is breadth. Choosing Meelo means giving up the multi-media library that a Jellyfin install provides, and accepting a smaller project with a wiki-based setup path. If you want one server for films, shows and music, Meelo is the wrong tool regardless of how good its grouping is. If music is the whole point and editions matter to you, the model is the reason to pick it.

Maintenance, Upgrade Path and Who Should Wait

Release cadence is visible from the tags: v3.11.0 in May 2026, v3.11.1 in July 2026, v3.12.0 in August 2026, with the last push to main in September 2026. That is a steady minor-release rhythm rather than a long-term-support schedule, and the README does not describe an upgrade procedure or a migration policy. Because Meelo runs from Docker images and parses your files into its own database, the thing to protect is your metadata and your library, not the container. Verify before you commit to it: that the wiki's Docker instructions cover your host, that your tags produce the release and track groupings you expect on a test subset, and that you are comfortable with the GPL-3.0 terms if you plan to fork. The README's own closing line asks you to get the most out of your music collection, and that is the honest framing. Meelo rewards a collection that has already been curated and punishes one that has not.

Editorial conclusion

Adopt Meelo if you maintain a carefully tagged collection and want release, track and version grouping plus music videos in the same library. Do not adopt it if you need a public-facing service (the README states it is for private use only and not built for heavy traffic), or if you are unwilling to tag files first. Before committing, verify two things: that your tags actually populate the release and track fields you expect, and that the wiki's Docker instructions match your deployment target, since the README only points there and ships no compose file of its own.

Official sources

1. Arthi-chaud/Meelo on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases