Radarr gives one movie one version, and that single rule shapes everything

Only one type of a given movie is supported

Radarr watches RSS feeds for new movies, talks to indexers and download clients to grab, sort and rename releases, then imports the finished file. The loop is well built. What constrains it is a single sentence: only one type of a given movie is supported, and if you want both a 4K version and a 1080p version of a film you need multiple instances.

That is the whole design in one line, and it is worth pricing before install. A dual-quality library is not a profile problem inside one Radarr, it is two Radarrs.

Anyone upgrading from a folder of mixed-quality files has to decide which single version each title becomes, and do that before the first import rather than after.

A manual search exists to explain the release Radarr skipped

Acquisition starts with RSS. Radarr monitors multiple feeds for new movies and can search for releases automatically, then imports what arrives. The import step is automatic, which is why sorting and renaming are what the project spends its effort on: recognising Special Editions and Director's Cut releases, identifying releases with hardcoded subs, and identifying releases that use AKA movie names.

The feature that makes this debuggable is manual search. You can pick any release yourself, and, in the project's own phrasing, see why a release was not downloaded automatically. That rejection reason is the thing to read when an item sits in your queue looking healthy and nothing arrives.

Automatic failed download handling closes the other half of the loop. When a grab fails, Radarr tries another release instead of parking the item, which keeps a queue moving at the cost of a log line you will only read when something goes wrong.

Profiles decide what gets grabbed, and the README leaves them to the wiki

Radarr can watch the movies you already have and upgrade them when a better format becomes available, the example given being a move from DVD to Blu-Ray.

That behaviour is driven by profiles, and the project describes them only as advanced customization for profiles, such that Radarr will always download the copy you want. No option name, no default profile, no example of a cutoff appears in the README. The wiki at wiki.servarr.com/radarr is where the documentation link goes.

The consequence for a new install is concrete: on day one your profile decides whether a release is accepted or rejected, and until you have read that page you cannot predict what the library will contain. Getting this wrong is cheap to fix later and expensive to discover after a year of automatic upgrades.

Download clients are integrated, not shipped

Radarr speaks to other software to move bytes. For Usenet there is full integration with SABnzbd and NZBGet. For torrents the listed clients are QBittorrent, Deluge, rTorrent, Transmission, uTorrent and others.

Nothing here is bundled. Radarr is a manager that tells a client what to fetch, and the client does the fetching. That shapes your first afternoon: the client has to exist, be reachable, and be authenticated before Radarr has anything to search against. Credentials for the indexer, the download client and the media server are all configured inside Radarr, so a first install touches three or four systems rather than one.

If you came from a plain torrent client, the mental model shift is that Radarr owns no transfer state of its own. A stalled download is a client-side problem, and Radarr's contribution to it is the retry that fires after the failure.

Plex and Kodi get notifications and a library refresh, not playback

The integration with Kodi and Plex covers notifications and library updates. Radarr tells your media server that files changed so it rescans and picks them up; it does not serve video and it is not a player.

Metadata travels in both directions. Radarr imports metadata such as trailers or subtitles, and adds metadata such as posters and information for Kodi and others to use. When a film is added it arrives with trailers, ratings and similar information attached rather than as a bare file, which is what makes a scraped library look organised rather than merely complete.

The one gap the README leaves is the one an integrator hits first. API documentation is published at radarr.video/docs/api/, so automation is clearly intended, but the README documents no key, header or authentication scheme for it. Treat the API as available and figure out the credentials from the wiki.

package.json says version 1.0.0, and that number is not the application

The root package.json carries version 1.0.0 and describes a PVR for Usenet and BitTorrent users. That version belongs to the frontend build only, wired through webpack at frontend/build/webpack.config.js, with yarn clean removing ./_output/UI and the source maps. The application version lives elsewhere, in the release tags: v7.0.1.10859 published on 2026-11-02, v7.0.0.10815 on 2026-10-25, and v6.4.4.10685 on 2026-09-16.

The default branch is develop, not master, so a clone gives you the integration branch rather than a release. build.sh, docs.sh and test.sh sit at the root alongside azure-pipelines.yml and a .devcontainer directory, which tells you the backend is built with shell scripts and CI while the interface is built with yarn and webpack.

The frontend stack is ordinary React work: connected-react-router, @tanstack/react-query, fuse.js for client-side search and @sentry/browser for error reporting. Whether that reporting is active in your install is a configuration question the README leaves open. Licence terms are GNU GPL v3, copyright 2010-2025, with the full text in LICENSE at the root.

Install questions go to the wiki, because the repository has no install command

There is no install command in this README, and there is no Dockerfile to copy. What the project offers instead is a documentation pointer, and the support section is explicit about where each kind of question goes. GitHub issues are for bugs and feature requests only. Configuration, setup and usage belong on the wiki at wiki.servarr.com/radarr, with a Discord for conversation, and a separate Docker installation page is linked directly from the README.

That division has a practical effect on a first install. You will spend the setup phase in the wiki rather than in the repository, and the repository itself will not tell you the port, the config path or the container flags. The Docker page is the one route the README itself endorses, so anyone deploying that way should start there rather than assembling a compose file from memory.

It also means the issue tracker is a poor place to report a misbehaving indexer or a failed grab. Those are environment questions, and the project routes them elsewhere on purpose.

Editorial conclusion

Radarr fits a household that wants one good copy of each film, sorted and renamed, driven by indexers and an RSS feed rather than by hand. It does not fit a library that keeps both a 1080p and a 4K copy, since the README answers that case with multiple instances rather than with a feature. Verify two things before committing: which download client and indexer you will point it at, since Radarr integrates with them but ships neither, and what your quality profile actually allows, because the upgrade rules live in the wiki rather than in the README. Releases v7.0.1.10859 and v7.0.0.10815 landed on 2026-11-02 and 2026-10-25 with the last push on 2026-11-02, and the source is GNU GPL v3 with copyright 2010-2025.

Frequently asked questions

Official sources

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