Radarr: a movie collection manager for Usenet and BitTorrent

What Radarr solves for people who collect films

The manual loop is familiar: check a feed, judge a release name, hand it to a download client, then move and rename the file so a media server can read it. Radarr is the automation of that loop for one medium. The README describes it as a movie collection manager for Usenet and BitTorrent users that can monitor multiple RSS feeds, interface with clients and indexers to grab, sort and rename releases, and then upgrade existing files when a better quality format appears.

The audience is narrow and specific. You need a download client, you need indexers, and you need a library that other software reads. If you have none of those, Radarr has nothing to manage. The project also assumes you understand the difference between an indexer and a client, because it sits between them and does not replace either.

One structural constraint shapes everything else: only one type of a given movie is supported. A 4K copy and a 1080p copy of the same film cannot live in one instance. The README says multiple instances are needed instead. That single sentence determines how much infrastructure you run before you have added a movie.

How the pipeline works: feeds, indexers, clients, library

Radarr is a long-running service with a web UI, written in C#. The repository layout shows a src/ directory for the backend, a frontend/ directory with a React and TypeScript interface built by webpack, and a distribution/ directory for packaging. The frontend package.json lists @microsoft/signalr, which is how the UI receives live updates from the server without polling.

The data flow is a chain. Radarr watches RSS feeds and performs its own searches for releases. When it finds a candidate, it compares that release against the quality profile you configured, which is the rule set deciding what Radarr should accept. Accepted releases are handed to a download client such as SABnzbd, NZBGet, QBittorrent, Deluge, rTorrent, Transmission or uTorrent. When the client finishes, Radarr imports the file, renames it, and writes metadata such as posters and information for Kodi and others to use.

Two behaviours matter in practice. Failed download handling retries another release when one fails, so a dead NZB does not stall the queue permanently. And manual search exists both to pick a release yourself and to see why a release was not downloaded automatically. That second use is the diagnostic path: when automation makes a choice you disagree with, the answer is usually in the profile, not in the release.

The README also lists recognition features that address real-world naming noise: Special Editions and Director's Cut, hardcoded subtitles, and AKA movie names. These exist because release names are inconsistent and the matching has to survive that.

Installing Radarr and running a first real search

The README points to the Servarr wiki for installation and lists Windows, Linux, macOS and Raspberry Pi among supported platforms. Docker is documented there too, and the README's Docker badge links to the wiki's Docker page rather than embedding instructions. Because the repository does not carry install steps, use the wiki page for your platform and do not improvise a package name.

With the service running, open the web UI. The default port is a frequent question, and the wiki's installation pages are where it is stated for your platform and container; confirm it there rather than assuming. The API is documented separately at radarr.video/docs/api/ if you intend to script against it.

The first useful action is not adding a movie. It is connecting a download client, because nothing can be grabbed until one exists. In the web UI, go to Settings, then Download Clients, and add the client you already run. The README names SABnzbd, NZBGet, QBittorrent, Deluge, rTorrent, Transmission and uTorrent as supported and integrated. After saving, use the test button the UI provides for the client; a successful test confirms host, port and credentials before any queue work depends on them.

Next, add an indexer under Settings, then Indexers, and test it the same way. Only then add a movie and let Radarr search. If a search returns nothing, the manual search view is the place to look: it shows releases Radarr can see and lets you pick one by hand, which separates an indexer problem from a profile problem.

The frontend build, if you are working from source rather than an installed build, is driven by the scripts in package.json. The repository defines them as follows:

"scripts": {
  "build": "webpack --config ./frontend/build/webpack.config.js",
  "start": "webpack --watch --config ./frontend/build/webpack.config.js",
  "lint": "eslint --config frontend/.eslintrc.js --ignore-path frontend/.eslintignore frontend/"
}

Running the build script produces the UI bundle that the backend serves, and the start script rebuilds it on change during development. The lint script checks the frontend tree against the repository's own ESLint configuration.

The one-movie-one-quality rule and other limits

The clearest limitation is stated in the README: only one type of a given movie is supported. If you want both a 4K version and a 1080p version, you need multiple instances. That is not a configuration quirk, it is a design boundary, and it has real costs. Two instances mean two databases, two sets of indexer credentials, two download client entries, and two things to upgrade. Anyone planning a mixed-resolution library should decide this before importing anything, because splitting later is more work than starting split.

Quality upgrades are also a trade-off rather than a free win. Radarr can watch for better quality and upgrade an existing file automatically, for example from DVD to Blu-Ray. That means disk usage grows over time as files are replaced, and a library that was stable can change underneath you when a new release appears. The upgrade behaviour is governed by profiles, so a profile that is too permissive will keep replacing files you were happy with.

Radarr is the wrong tool if you do not want a service managing your files. It renames and moves things. If your library layout is hand-curated and you do not want software touching it, the import step is exactly the behaviour you are trying to avoid. It is also the wrong tool for television: the README describes movies only, and the related searches around Radarr and TV point at a different project in the same family.

Finally, the README does not document rollback of an upgrade or a way to pin a file permanently against replacement. If that matters to you, treat it as unverified rather than assume it exists.

Radarr against Sonarr and plain download clients

The most common comparison is Radarr against Sonarr, and the split is by medium. Radarr handles movies; Sonarr handles television. They share a lineage and a similar shape, which is why people run both and why the searches about using them together are so frequent. Installing both does not merge their libraries: each keeps its own database and its own notion of what it is tracking. The practical difference is the unit of work. A film is a single file with a single quality decision. A series is a season and an episode list, with ongoing additions that never really finish. That is why the two remain separate services rather than one with a mode switch.

The other comparison is against using a download client directly. A client like qBittorrent or SABnzbd can watch an RSS feed and download what matches a filter. What it cannot do is judge a release against a quality profile, retry a different release after a failure, rename the result into a library convention, or fetch metadata for a media server. Those are the four jobs Radarr adds, and they are the reason it exists as a layer above the client rather than a feature inside one.

If your needs stop at downloading files and you rename them yourself, the client alone is simpler. Radarr earns its place when the renaming and the metadata are the tedious part.

Maintenance, releases and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent and versioned in a four-part scheme: v6.4.4.10685 on 2026-09-16, v6.4.4.10684 on 2026-09-13, and v6.4.3.10645 on 2026-08-31. That cadence means the upgrade question is not whether updates arrive but how you take them.

How you upgrade depends on how you installed. A container image is replaced by pulling a new tag; a native install follows the wiki's instructions for your platform. The README does not document an in-place upgrade procedure or a rollback path, so the wiki is the source to check before you update, and a database backup before upgrading is the only reversible step you control.

The licence is GPL-3.0, with copyright stated as 2010-2025 in the README. For self-hosting, the practical implication is that if you modify Radarr and distribute it, the GPL's source-availability terms apply to your version. Running it privately for your own library does not trigger distribution. This is a description of the licence, not legal advice; if you plan to redistribute a modified build, read the licence text yourself.

Editorial conclusion

Adopt Radarr if you already run a download client and want a single service to watch feeds, pick releases and rename files into a library that Plex or Kodi can read. Do not adopt it if you need two quality tiers of the same film in one instance, since the README states only one type of a given movie is supported and a 4K plus 1080p setup needs multiple instances. Before committing, verify on the wiki which install path applies to your platform, confirm your download client appears in the supported list, and decide whether a single instance is enough for your library. The last push to the repository was on 2026-09-20, so the project is still moving.

Frequently asked questions

Official sources

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