autobrr: IRC announce filtering for the first minutes of a swarm
Modern, easy to use download automation for torrents and usenet.
At a glance
- What is it?
- autobrr listens to tracker IRC announce channels and RSS or Newznab feeds, applies RegEx-capable filters, and pushes matching releases to torrent clients, the *arr apps, or Usenet downloaders. It is a Go and React application under GPL-2.0, and its value depends entirely on how fast your indexers announce.
- Who is it for?
- Adopt autobrr if your indexers announce on IRC and you want the release in a client before the RSS poll cycle notices it, and if you are willing to run a long-lived daemon that holds credentials for trackers and download clients. Skip it if every indexer you use is RSS-only, or if you want a single binary that owns the whole download lifecycle.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap autobrr is built to fill: RSS polling versus IRC announce
The README is explicit about the problem. Radarr and Sonarr look for new torrents over RSS, and RSS is updated regularly but too slow to put you in what the project calls the initial swarm. Ratio comes from seeding, and seeding early is what puts your client in front of peers. If a release is ten minutes old by the time your stack sees it, you are competing with everyone who already had it.
Many indexers publish new torrents to IRC the moment they are uploaded. autobrr connects to those channels, watches the announce lines, and matches them against filters you define. A match triggers an action: the torrent file goes to qBittorrent, Deluge, rTorrent, Transmission, Porla, or aria2, or to Sonarr, Radarr, Lidarr, Whisparr, Readarr, or Sportarr, or into a watch folder, an exec script, or a webhook. The intended audience is self-hosters running a seedbox or home server who care about ratio and about catching releases early. It is not a download client and it does not replace one.
Announce line in, filter match, action out
The data path has three stages. Input is either an IRC announce from a supported tracker or a feed item from RSS, Torznab, or Newznab. Filtering is where the project spends its complexity: the README describes filtering as powerful but simple, with RegEx support in the style of autodl-irssi. Actions are the output side, and they are attached to the filter rather than configured globally, so one filter can send to qBittorrent while another sends to Radarr.
Two details shape how you deploy it. First, one autobrr instance can talk to multiple clients on remote servers, so the daemon does not have to sit on the same host as qBittorrent or SABnzbd. Second, RSS indexers are treated the same way as IRC indexers inside the application, which means a single filter vocabulary covers both sources. Usenet is handled through Newznab feeds, and matches can go to the *arr apps or straight to SABnzbd and NZBGet. Magnet links are supported as well. The web UI, built on React, is where filters, indexers, clients, and notifications are managed; the README notes it is mobile friendly and has a dark theme.
Installing autobrr on a seedbox, in Docker, or from a generic Linux build
The fastest path is a managed seedbox. Swizzin users run sudo box install autobrr. Saltbox users run sb install autobrr. QuickBox users run qb install autobrr -u ${username}. HostingByDesign (formerly Seedbox.io) and Swizzin.net both expose box install autobrr, and Seedit4.me, SeedHost.eu, Ultra.cc, and Whatbox.ca are listed as supporting platforms. Whatbox requires enabling its Expert mode for external connections.
Outside those panels, the README points to a Docker Compose setup and notes distroless images are available, plus Windows, macOS, and generic Linux builds. Environment variables are documented as a configuration surface. The README defers the details: it sends you to the installation guide at autobrr.com/installation/linux and to the configuration guide at autobrr.com/configuration/autobrr for wiring up indexers, IRC, and download clients. That is the honest boundary of what the repository front page gives you. There are no filter examples, no environment variable names, and no Compose file in the material I have, so treat the documentation site as required reading rather than optional.
Two configuration choices are worth deciding before you start. The database engine can be PostgreSQL or SQLite, and authentication can be the built-in mechanism or OpenID Connect. A base path and subfolder are supported for reverse proxies, which matters if autobrr shares a domain with other services.
Where autobrr stops being the right tool
The project is only as fast as its inputs. If your indexers do not announce on IRC, autobrr falls back to RSS, Torznab, or Newznab, and you have paid the cost of running another daemon to do what your existing stack already does on a poll cycle. The README acknowledges this directly: a lot of indexers do not announce in IRC channels, which is why feed support exists at all. For an RSS-only setup, the early-swarm argument does not apply.
The second limitation is operational. autobrr holds credentials for tracker IRC servers and for every download client you connect, and it runs continuously. A filter with a poorly written RegEx will match the wrong releases and push them to a client before you notice, and the README's own framing of RegEx support as inherited from autodl-irssi is a reminder that this is a power feature with a matching failure mode. There is also no claim in the material that autobrr deduplicates against releases already grabbed by Sonarr or Radarr. If both paths are active, you are responsible for keeping the filter set tight enough that they do not fight over the same release.
autobrr versus autodl-irssi and flexget
The README names its predecessors: trackarr, autodl-irssi, and flexget. autodl-irssi is an IRC announce client that runs inside an IRC client, typically irssi, with Perl configuration files. autobrr takes the same core idea, IRC announce matching with RegEx, and moves it into a standalone Go daemon with a web UI, a database, and a REST-era action model. The practical difference is where configuration lives: text files and an IRC session versus a browser form and a SQLite or PostgreSQL database.
flexget is the other direction. It is a general automation tool driven by YAML recipes, and it covers far more than tracker announces. autobrr is narrower by design and trades that breadth for a UI and for first-class integrations with torrent clients, the *arr apps, and Usenet downloaders. If you already maintain flexget recipes you are comfortable with, autobrr is not a superset of them. If you want an interface you can hand to someone else, or you want OIDC in front of the daemon, autobrr is the more conventional choice.
Release cadence and what it costs to stay current
The release history shows a steady rhythm: v1.84.0 on 2026-08-13, v1.85.0 on 2026-08-27, v1.86.0 on 2026-09-10, roughly every two weeks, with the default branch named develop and the latest push landing minutes before the release tag. That cadence is the maintenance cost. Tracker announce formats change, indexers add and remove IRC servers, and client APIs move. A project shipping every two weeks is absorbing that churn for you, but it also means upgrades arrive often enough that you should decide on a policy rather than upgrade reactively. Container users have the easier path here, since the README documents Docker and Kubernetes support and distroless images.
On licensing: autobrr is GPL-2.0. That is a copyleft license. If you run it as a service for yourself, the practical obligation is minimal. If you modify it and distribute the modified binary, or build a product around it, the terms differ from a permissive license and you should read them rather than take my summary. Nothing here is legal advice.
Who should run autobrr, and what to check first
Run it if you are on a seedbox or a home server, your indexers announce over IRC, and you want releases in qBittorrent, Deluge, rTorrent, Transmission, or an *arr app within seconds of the announce. Run it if you want one filter model covering both IRC and Newznab feeds, and you would rather manage that in a browser than in a config file.
Do not run it if every indexer you use is RSS-only, or if your Sonarr and Radarr setup already catches what you need at a rate you find acceptable. Do not run it if you are unwilling to keep a daemon with tracker and client credentials online, or if a stray RegEx match reaching your download client would be a serious problem for your ratio or your disk.
Before you install, verify three things. Check that your trackers appear in the documented IRC support list, since that list is the whole premise. Decide between SQLite and PostgreSQL up front, because migrating later is work you can avoid. And read the configuration guide at autobrr.com/configuration/autobrr before you write your first filter, because the repository front page gives you the shape of the filter and action model but not the syntax. If those three checks pass, the install is one command on most seedbox panels and a Compose file everywhere else.
Editorial conclusion
Adopt autobrr if your indexers announce on IRC and you want the release in a client before the RSS poll cycle notices it, and if you are willing to run a long-lived daemon that holds credentials for trackers and download clients. Skip it if every indexer you use is RSS-only, or if you want a single binary that owns the whole download lifecycle. Before committing, confirm that your trackers are covered by the documented 100+ IRC list, decide between SQLite and PostgreSQL, and check whether the *arr apps you already run can cover the same releases through their own indexer configuration.
Community notes