Components
- Indexers - Newznab-compatible sites that crawl headers and publish NZBs.
- Prowlarr / NZBHydra2 - one place to manage indexer APIs, caching, and rate limits.
- Sonarr / Radarr / Lidarr - track wanted media, grab NZBs, rename, and shelve files.
- SABnzbd / NZBGet - download engine talking NNTP to your providers.
Recommended wiring
- Configure providers in SABnzbd (primary + optional fills) using the SABnzbd guide.
- Add indexers inside Prowlarr; sync apps from Prowlarr.
- Point Sonarr/Radarr download client at SABnzbd's API.
- Use categories so completed downloads land in the right root folders.
Indexers vs providers
Indexers do not host the binaries. If retention on your provider is shorter than the release age, no indexer can save the download. That is why backbone retention and fill diversity matter before you tune quality profiles. Pick primaries from the matrix and fills from best blocks.
Quality profiles and fails
When Sonarr/Radarr report repeated failures, check provider completion before blaming indexers. Swap NZBs, confirm SSL, and ensure optional fills are on a different backbone (backbone map). DMCA-heavy primaries benefit from NTD/independent fills - DMCA vs NTD.
Minimum viable automation
You do not need every *arr on day one. Order: working SABnzbd download, one indexer, then Sonarr or Radarr, then Prowlarr consolidation. Beginners can delay automation entirely with a web reader - beginners hub.
FAQ
- Can automation fix a bad provider choice?
- No. Automation multiplies a good stack; it cannot invent articles a backbone already deleted.
- How many indexers do I need?
- Start with one or two reputable indexers. Add more only after you measure misses.
- SABnzbd or NZBGet for *arr stacks?
- Either works. Most desktop/NAS users pick SABnzbd for UI comfort.