# ADR 017: Prowlarr manages the indexers

- HTML version: https://robbiepalmer.me/projects/homelab/adrs/017-prowlarr-indexer-management
- Project: Home Lab (https://robbiepalmer.me/projects/homelab.md)
- Status: Accepted
- Date: 2026-08-23

# Context

Sonarr and Radarr both need torrent indexers to search, which raises a fair
question: with only two apps, isn't a dedicated indexer manager one service
too many?

The constraint that decides it: Sonarr ships no native support for the
major public trackers — its built-in list is mostly private trackers plus a
couple of public specials. To reach them from Sonarr you need a Torznab
endpoint, which means running an indexer proxy anyway. Radarr does ship one
native movie-tracker implementation, so for movies alone Prowlarr would be
optional. For TV it isn't.

# Decision

Run **Prowlarr** as the single indexer manager. Indexers are defined once,
tested once (the UI shows per-indexer health and last-search status), and
synced to Sonarr and Radarr automatically. Adding a third app later needs
zero indexer work.

Provisioning registers Prowlarr as an *application* to each app with its API
key and container hostname (`http://sonarr:8989`), so the sync runs over the
Compose network, not localhost.

# Alternatives

## Native per-app indexers

* **Pros**: One less container, fewer API keys floating around.
* **Cons**: Sonarr gets no coverage of the major public trackers at all;
  Radarr's one native definition covers only movies. Each new indexer gets
  configured twice with different schema shapes.
* **Decision**: Rejected for TV; would fragment movies onto a different
  mechanism than shows use.

## Jackett

* **Pros**: The older, lighter indexer proxy; exposes Torznab feeds fine.
* **Cons**: The Servarr projects themselves steer people from Jackett to
  Prowlarr now. With Jackett I'd still wire Torznab endpoints into each app
  by hand, and indexer health checks live in yet another UI instead of being
  pushed into the apps' own dashboards.
* **Decision**: Rejected. Same job, more manual wiring, upstream treats it as
  the legacy path.

## Skip TV automation, keep manual grabs for shows

* **Pros**: Radarr's one native tracker definition would cover movies with
  no extra service.
* **Cons**: Covers movies only, leaving TV outside the automation.
* **Decision**: Rejected. It optimizes the half of the library I touch least.

# Consequences

### Pros

* One definition per indexer, tested in one place, synced everywhere.
* Search debugging happens in Prowlarr's UI before touching either app.
* App onboarding is trivial: register the app, get all indexers.

### Cons

* One more container (\~200MB RSS) on the VM, doing a job that is only partly
  necessary. If Sonarr ever ships native support for major public trackers,
  this ADR should be revisited honestly: Prowlarr would then be redundant
  for our two-app setup.
* Indexer reachability problems concentrate here. Some aggregator sites
  refuse Prowlarr's .NET TLS fingerprint entirely (wget connects, .NET gets
  cut mid-handshake); those definitions stay out of the provisioned set.
* A single TV tracker proved too thin in practice during end-to-end testing:
  its search endpoint returned zero results for two aired episodes that
  other public trackers carry with thousands of seeders. Provisioning
  therefore spans four definitions across several public trackers, each
  validated live from this network before being committed.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt