When autobrr adds a useful layer
If your existing feed workflow already finds the releases you want at an acceptable time, first identify what another service would improve. autobrr's introduction explicitly says its RSS support is unnecessary when your only use is feeding the *arr applications, which already support RSS.
The stronger reason to evaluate autobrr is its combination of IRC announcements, filters, and configurable actions. The README describes monitoring tracker announce channels and forwarding matching torrent files directly to clients or through Sonarr and Radarr. In the latter arrangement, the library manager decides whether to accept the release before forwarding it to its downloader.
The README claims support for 100+ trackers with IRC announcements, along with Torznab, Newznab, regular RSS, magnet links, and Usenet. It lists qBittorrent, Deluge, rTorrent, Transmission, SABnzbd, NZBGet, *arr applications, watch folders, scripts, and webhooks among its clients and actions. These are documented capabilities, not integrations verified in our run. Earlier swarm participation is the project's stated rationale for IRC monitoring; we did not measure announcement latency or seeding outcomes.
What our recorded run establishes
Our stored run took place on September 24, 2026, at commit 62c4a6dff1c493ad8bc08bbbdfcdb3b453c25274. This is a commit-specific observation, not a test of every release or a fresh execution for this correction.
The dependency/setup step exited with code 0 after 35.721 seconds, rounded to 36 seconds in the harness. Its retained output shows go: downloading go1.27.0 (linux/amd64). The dependency summary records 169 entries; it does not establish that 169 application packages were installed or that the autobrr CLI was installed.
The harness's build-labeled step exited with code 0 after 93.823 seconds, rounded to 94 seconds. The retained output is vet-exit:0. Without the full command or an artifact check, that record does not verify compilation, a runnable server, or an installed binary.
The Go test step exited with code 0 after 39.556 seconds, rounded to 40 seconds. The parser summary records 70 successful package results, zero failed package results, and 45 package entries with no test files. Go package results are not individual test cases. The retained output includes repeated package lines, and no complete-log reconciliation established exhaustive unique counts. The supported conclusion is that the recorded test command exited successfully, not that exactly 70 individual tests passed.
The configured environment had 3 CPUs, 8 GB of memory, and image golang:1.24-bookworm. That image name is not proof of the executing Go version, particularly given the recorded Go 1.27.0 download. The checkout measured 7 MB, with 1,017 files and about 125,907 source lines. Detection found 9 CI workflow files, a Dockerfile, a Compose file, and a tests directory.
The supplied run contains no installed-binary check or measured live IRC, indexer, downloader, or Usenet workload. It provides no latency benchmark, parser-accuracy result, action-delivery measurement, or security-audit result.
Configuration matters more than the command timings
The README separates installation from configuring indexers, IRC, and download clients. Budget time for those connections and for checking that filters produce the intended actions. A practical first evaluation is one source, one narrow filter, and one destination, followed by inspection of the activity before expanding the rules.
The documented defaults are SQLite and 127.0.0.1:7474. PostgreSQL, built-in authentication, OIDC, and reverse-proxy base paths are available. The README recommends a reverse proxy for internet exposure, while its Compose example publishes port 7474. Check the deployment's actual bind address, published ports, and authentication rather than assuming the native default describes container exposure.
The README also lists optional metrics on 127.0.0.1:9074 and profiling on port 6060, and supports reading environment-variable values from files. These configuration options were not exercised in our recorded run.
The alternative distroless image has a specific compatibility limit: the README says external filters and exec actions require compiled static binaries because the image has no shell. Bash and sh scripts will not work there. Choose the standard image if those scripts are part of your workflow. We did not compare the images' security or runtime behavior.
Read issue reports with their versions and status
Issue 2702 remains open in the supplied extract. Its reporter describes autobrr 1.85.0 on Windows downloading the same episode twice when parsed titles differed by a colon. The reporter explicitly says they could not upgrade and reproduce the behavior on the latest version. Treat this as a reason to check your duplicate profile against real title variations, not proof that version 1.86.0 has the same defect.
Issue 2686 reports IPT announcements observed with version 1.86.0 whose GB labels appeared to represent binary quantities but were parsed as decimal bytes. The reporter linked that discrepancy to rejected cross-seed candidates. The supplied issue history shows it was closed as completed in #2730 on October 3, 2026. That is a historical, tracker-specific report with a recorded completion status. The supplied evidence does not identify the first released version containing the change or show that our September run validated it.
The v1.86.0 release notes list an external-filter Test button, downloader changes, dependency updates, and a session-cookie Secure-attribute fix. Those notes describe upstream changes; they do not turn our commit-specific command results into release-wide compatibility or security findings.
Alternatives and a useful next step
autodl-irssi is relevant if you want an irssi plugin that monitors IRC announcements and downloads torrent files according to filters. FlexGet is relevant if you need YAML-configured content automation using sources such as RSS, HTML pages, CSV files, or search engines. Neither alternative was run for this review.
For autobrr, write down the missing capability before installing it: acting on IRC announcements, applying shared filters, or routing matches to several clients. Then validate that capability with your own source and destination. If existing *arr RSS handling already covers the job, the project's own introduction gives you a reason to keep the simpler setup.
How the ratings work
These are editorial evidence ratings, not benchmarks. On this five-point rubric, 1 means the supplied evidence shows a substantial obstacle, 2 means important adoption questions remain unresolved, 3 means there is a documented basis for evaluation with material limits, 4 requires stronger direct validation, and 5 requires broad validation across the relevant workflows. Unknown adoption and untested compatibility do not earn high scores.
Setup receives 3 because installation routes and successful command-step exits are recorded, but a working binary and integrations were not verified. Documentation receives 3 because the supplied README and introduction explain installation, configuration, routing, and a concrete container limitation; we did not validate the full documentation. Community receives 2 because contribution and support routes are documented, but response times and sustained participation are unmeasured. Maturity receives 3 because release notes, issue handling, and successful test-step execution provide a basis for evaluation without establishing production reliability.