What Is the Arr Stack? Sonarr, Radarr, and Prowlarr Explained

If you’ve spent any time in homelab or self-hosting circles, you’ve seen people mention their “Arr stack” — often written *arr, where the asterisk is a wildcard standing in for Sonarr, Radarr, Lidarr, and friends. It sounds like arcane jargon, but the idea is simple: a set of apps that turn “I want to watch this” into an organized file in your library without you touching a download client.

This post explains what each piece does and how they fit together — the concepts, no setup yet. The deploy guide covers actually standing it up, and the automation guide covers wiring it to your media server.

The problem the Arr stack solves

Think about what managing a media library by hand actually involves. You search a dozen indexers for the thing you want, squint at release names trying to guess which one is good, download it, wait, rename the file into something your media server’s scanner understands, move it into the right folder, and refresh the library. Then you do it again for the next episode. And the next. It’s the kind of chore that starts as a hobby and quietly becomes a part-time job.

The Arr stack automates every step of that. You tell it what you want — that’s the whole job description — and it handles the searching, the grabbing, the renaming, and the filing, then tells your media server to rescan so the title just appears, ready to watch.

One thing I learned running this myself: “hands-off” holds right up until the auto-downloading quietly stops. Nothing errors and nothing pages you — the library just stops growing, and because everything still looks fine, you don’t catch it for a while. The stack is worth building; just build it so you’ll notice when one link stops handing off to the next. That’s what pushed me toward a self-healing setup.

The players

Each app is a focused piece of the pipeline. All are open-source and part of the Servarr family, so they share a near-identical interface.

How Prowlarr changed the game

An indexer, if the term is new to you, is a searchable catalog of available releases — a torrent tracker or a Usenet index. The Arr apps need at least one to have somewhere to look. Before Prowlarr existed, you added every indexer to Sonarr and Radarr separately: configure a tracker twice, keep two credential sets current, and repeat the whole exercise every time an indexer changed. Multiply that by every app in the stack and it got painful fast.

Prowlarr is the indexer manager: you add each indexer once, in Prowlarr, and it syncs that indexer into every connected Arr app automatically. Add or remove a source in Prowlarr and the change propagates everywhere. Prowlarr stores the indexer definitions; Sonarr and Radarr are registered as “applications” inside it and receive the synced indexers.

The pipeline, end to end

Here’s the full loop, from “add a movie” to “ready to watch”:

You add a title  (or an import list adds it automatically)
      │
      ▼
Radarr / Sonarr   ── decides it's "wanted", asks Prowlarr's indexers
      │
      ▼
Prowlarr indexers ── return candidate releases, scored by quality rules
      │
      ▼
Download client   ── grabs the chosen release (torrent behind a VPN)
      │
      ▼
Radarr / Sonarr   ── imports: renames + moves the file into the library
      │
      ▼
Media server      ── rescans; the title appears, ready to stream

Every arrow is automatic. The only human input is the first line — and even that can be automated with import lists that pull from a watchlist or “popular” feeds.

Where quality rules fit in

The Arr apps don’t grab the first result they find. Each uses a quality profile — your rules for resolution, source, file size, and codecs — to score candidate releases and pick the best one that fits. This is why you can say “prefer 1080p Blu-ray, never grab a cam, cap the file size” and have it enforced on every download. The community-maintained TRaSH Guides are the reference for tuning these; the automation guide covers them.

What about a VPN?

A common worry: does all of this need a VPN? Only one piece does. Sonarr, Radarr, and Prowlarr move metadata and searches — no swarm traffic. The download client is what joins torrent swarms and exposes your IP. So the standard hardened setup routes only the torrent client through a VPN container with a kill-switch, leaving the rest on your LAN. The VPN Torrent Stack playbook does exactly that.

What’s next

Now that the pieces make sense, the next step is standing them up — and it’s easier than the number of moving parts suggests. The deploy guide runs the whole stack in one Docker Compose file — Prowlarr, Radarr, Sonarr, and a VPN-shielded qBittorrent — with the folder layout that makes everything downstream work smoothly. Read the concepts here once, and the setup steps there will feel like connecting dots rather than following incantations.

Related posts:

• Deploy the Arr Stack with Docker Compose — stand up the whole stack in one file
• Automating the Arr Stack: Import Lists, Quality Profiles, and Your Media Server — the hands-off part
• VPN-Shielded Torrent Stack — the download client, behind a kill-switch
• Install Plex Media Server on a NAS or Proxmox LXC — the media server the stack feeds
• Docker on Proxmox: LXC vs VM, Done Right — where to run the containers

Sources: Servarr Wiki, Prowlarr, TRaSH Guides.