Lidarr: a music collection manager for Usenet and BitTorrent

What Lidarr manages that a download client does not

A download client fetches a file. It does not know that the file is a 2019 remaster of an album you already own in lossless, and it will not rename it to match the rest of your library. Lidarr sits above the client and keeps that state. The README describes it as a music collection manager for Usenet and BitTorrent users, and the feature list is really a list of the gaps it fills: it detects new tracks, scans an existing library and downloads anything missing, watches for better quality versions of files you already have, and retries with another release when a download fails. The intended user already has a library on disk and an indexer account. Lidarr is not a player, not a streaming service, and not a source of music by itself. It is the coordinator between an indexer, a download client and a folder of files.

How the monitor, indexer and download client fit together

The data flow is a loop. You add an artist, Lidarr reads the artist's releases from its metadata source, and it compares that against what is in your library folder. Anything missing becomes a wanted item. Lidarr then queries the indexers you configured, either on a schedule or when you trigger a search, and picks a release according to the quality profile you set. That release goes to the download client. When the client finishes, Lidarr imports the file, renames it according to your naming configuration, and updates the artist's status. The same loop runs in reverse for upgrades: if a better quality format appears, the README states that Lidarr can be configured to automatically upgrade files already downloaded. Failed downloads are handled by trying another release. A manual search exists so you can pick a specific release or see why an automatic search did not produce one. The repository itself is a C# backend under src/ with a React and TypeScript frontend under frontend/, built through webpack, so the web UI you configure is the same application serving the API.

Installing Lidarr with Docker Compose

The README points to the Servarr wiki installation page for platform packages, and the Docker badge links to the same wiki. There are no install commands in the README itself, so the Compose file below is not copied from the project. What the README does confirm is that Docker is a supported path and that the project runs on Windows, Linux, macOS and Raspberry Pi. A Compose service needs a config volume and a library volume; the default port is 8686, which is the value the project's own documentation uses for the web UI.

Your first real use: add an artist and a quality profile

Start the container and open the web UI on port 8686. The first screens ask for a download client and an indexer before anything can be grabbed. The README names SABnzbd and NZBGet as the Usenet clients with full integration; torrent clients are supported through the same download client settings. Once a client and an indexer are saved, add an artist and let Lidarr read the discography. The library import is where the current caveat bites: the README carries a warning that the Lidarr Metadata Server is recovering and rebuilding its cache, which is impacting adding artists and library imports. If the artist list stays empty or an import stalls, that is the known cause, not your configuration. After the artist appears, trigger a search from the artist page and watch the queue. Files that import successfully are renamed according to the naming settings, and the README notes integration with Kodi and Plex for notification, library update and metadata.

Where Lidarr is the wrong tool

Lidarr assumes you own files and want more of them. If you listen through Spotify, there is nothing for it to manage, because it has no connection to a streaming catalogue. If you want a single search box that downloads one album and stops, the indexer, download client and quality profile setup is more machinery than the task needs. The metadata warning in the README is a live limitation rather than a theoretical one: adding artists and importing a library depend on a server the project says is rebuilding its cache, and the README directs users to GitHub issue 5498 and Discord for the current state. There is also a structural constraint in how the loop works. Lidarr can only find what your indexers return. A release that no indexer carries is invisible to it, and the manual search will show an empty result rather than an error. That is a property of indexer-based acquisition, not a bug, but it decides whether the tool is useful for the music you actually want.

Lidarr compared with a plain download client

The honest alternative is to skip Lidarr and use the download client directly with RSS. SABnzbd and NZBGet both accept feeds and can filter them, so a careful user can follow a few artists without a second application. The difference is state. A download client does not know your library, so it cannot tell you that you already have the album, cannot rename what it downloads into your folder structure, and cannot decide that a FLAC is worth replacing an existing MP3. Lidarr's whole value is that comparison against the library plus the rename step. If your collection is small, or you do not care about consistent naming, the extra layer is overhead. If your collection is large and you want new releases from dozens of artists handled without manual checking, the client alone will not do it.

Maintenance, releases and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-14. Recent releases are frequent: v3.1.6.5078 on 2026-09-13, v3.1.5.5066 on 2026-09-06 and v3.1.4.5029 on 2026-08-23. That cadence matters for upgrade cost, because a Docker image pinned to latest will move with it. Pinning to a specific tag such as 3.1.6.5078 is the way to control when the application changes underneath you, and the config volume should be backed up before a version jump because the database lives there. Lidarr is licensed under GPL-3.0, with the README stating GNU GPL v3 and copyright 2010-2021. For normal self-hosted use that means you can run it and modify it, and if you distribute a modified version you have obligations under the same licence. This is a description of the licence text, not legal advice; check the terms yourself if you plan to redistribute a build.

Editorial conclusion

Lidarr fits people who already own a music library and run SABnzbd, NZBGet or a torrent client, and who want new releases from followed artists pulled in automatically. It does not fit anyone who streams from Spotify, or who wants a one-click downloader with no indexer and no library folder. Before adopting it, verify that your indexers are still reachable, because the README warns the Lidarr Metadata Server is recovering and rebuilding its cache, which affects adding artists and library imports. Check GitHub issue 5498 for the current state before you point it at a large existing library.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Lidarr/Lidarr on GitHub
3. Project website
4. README
5. Releases