Sonarr automates TV files after you supply the sources
Sonarr has one narrow job: manage TV episodes obtained through Usenet or BitTorrent. It watches feeds, searches for missing episodes, sends a release to SABnzbd, NZBGet, or another configured client, and imports the completed file. The 4.0 series can rename episodes, retry failed downloads, and replace an existing copy when a quality profile allows an upgrade. Plex and Kodi integrations can then request a library refresh. Sonarr never supplies the indexer account, download service, or media itself.
That division of labor makes Sonarr useful inside an existing media stack and confusing as a first step into self-hosting. The quick-start guide says to add at least 1 indexer, then connect a download client and choose a separate media root. Most Usenet indexers need an API key. Torrent trackers commonly arrive through Prowlarr or Jackett. Each part can work alone while the complete chain still fails because one path, category, or credential differs.
Quality profiles decide when an episode is good enough
Sonarr's strongest feature is its policy engine. A profile defines acceptable qualities and a cutoff, so a 720p file can be accepted now and replaced later by a preferred 1080p release. Manual search shows candidates and explains rejection decisions, while custom naming can preserve quality, release group, codec, language, and series identifiers. Version 4 also handles specials and multi-episode files, which matters for libraries whose filenames rarely match one tidy pattern.
Automation still needs supervision around unusual packs. Open issue 8938, updated on September 11, 2026, describes v5 work for releases that span several seasons. Its proposed scope leaves automatic search, RSS, and upgrades out of the first solution. People archiving a completed show as one multi-season download should expect manual handling until the behavior they need is released and verified. Sonarr is much more comfortable with episodes and ordinary season packs.
What happened when we ran it
Our sandbox cloned commit 91c4ae1 and installed 908 Yarn packages in 147 seconds. Dependencies occupied 383 MB after installation. The checkout itself was 20 MB, with 4,809 files and roughly 325,049 lines of source. On the same unprivileged container with 3 CPUs and 8 GB of RAM, the build finished successfully in 50 seconds. Those figures make the web development path practical, though the dependency tree is substantial.
The package build calls webpack for Sonarr's frontend. We found no test script or target that our lab could invoke, so tests were skipped. That is not a passing test result, and the 50-second build does not prove indexer searches, downloads, imports, or upgrades on a running server. The repository scan counted 12 CI workflow files, while its expected root had no Dockerfile or tests directory. No install failure or compiler error appeared in the measured steps.
One shared mount prevents duplicate TV libraries
File layout causes more trouble than the browser setup suggests. Sonarr must read and write both the completed-download directory and final series directory. Its wiki warns that separate container mounts such as /tv and /downloads prevent hard links because they appear as different filesystems. A common /data mount keeps downloads and series under one filesystem. Without that layout, a torrent import may copy a large episode while the original remains for seeding.
Permissions are equally concrete. The service account needs write access to the media root and the downloader's output. Sonarr also trusts the path reported by the client, which may differ inside two containers and require remote path mapping. The project publishes no official Docker image; its wiki points users to third-party images and recommends Compose. That choice is workable, but image updates and container defaults belong to another maintainer.
Current activity is stronger than the June release date suggests
GitHub showed 15,631 stars, 90 combined issues and pull requests, and a last push on September 11, 2026. The latest stable release was v4.0.19.2979 from June 26, 2026, with a qBittorrent basic-auth fix. Same-day work included multi-season parsing, a v5 import redesign, API documentation, and cover-cache fixes. The repository is plainly active even though the latest release tag was more than 2 months old.
Open requests also expose operating edges. Issue 2477 asks for centralized authentication and has remained open while receiving a September 2026 update. Issue 8753 asks Sonarr to report database corruption and failed automatic backups through health notifications after a user found both together. Neither report proves every installation is affected. They do justify keeping the service behind deliberate access controls and checking that backups can be restored instead of trusting the presence of a backup page.
Sonarr earns its place in a TV-specific stack
Sonarr is the default recommendation here for people who already run the surrounding services. Its rule system is deeper than a folder watcher, and its v4 release plus active v5 branch show continuing maintenance. The cost is operational: at least 1 indexer, 1 downloader, shared paths, permissions, profiles, and backups must agree before the automation becomes dependable. A media server can consume Sonarr's output, but it does not replace any of those pieces.
Medusa, SickGear, and SickChill cover much of the same TV workflow with Python-based codebases and different provider or anime priorities. Sonarr is the better first trial for a conventional Plex or Kodi library because its setup guidance explains the whole chain and its community remains busy. Multi-season archives, centralized login requirements, or a desire for an official container should trigger a comparison before migrating an existing library.