What each piece actually does

The naming convention (everything ending in “-arr”) comes from Sonarr, the original of the bunch, and the rest followed the same pattern once they proved the model out. Each one owns exactly one media type and one job:

• Sonarr manages TV shows: tracks which episodes you want, monitors for new releases, and grabs them as they air.
• Radarr does the same job for movies.
• Lidarr covers music, Readarr covers books and audiobooks, Bazarr handles subtitle download and matching for whatever Sonarr/Radarr already pulled in. Most homelabs start with just Sonarr and Radarr and add the others only if they actually need that media type.
• Prowlarr is the indexer manager. Rather than configuring your indexers separately inside Sonarr, Radarr, and every other *arr app, you configure them once in Prowlarr and it pushes the configuration out to every app that’s connected to it. This one addition removed what used to be the single most annoying part of running more than one *arr app at a time.

None of these applications download anything themselves. They all hand the actual fetch off to a separate download client, most commonly qBittorrent for torrents or SABnzbd for Usenet. The *arr apps are the brains: deciding what to get, what quality to accept, when to search again if nothing suitable turned up yet, and what to do with a finished download. The download client is just the hands.

How a request actually flows through the stack

It helps to see the full path end to end before touching any configuration:

1. You tell Sonarr or Radarr what you want (add a show, add a movie), and set a quality profile (more on that below).
2. The *arr app checks Prowlarr’s connected indexers on a schedule, searching for a release that matches your quality profile.
3. When it finds a match, it sends the download to your configured download client (qBittorrent, SABnzbd, whichever you’ve set up) and tracks the job.
4. Once the download client reports the file complete, the *arr app picks it up, renames it according to your naming settings, and moves (or hardlinks, see below) it into your actual library folder.
5. Your media server (Plex, Jellyfin, Emby) picks up the new file on its next scan, exactly the way it would if you’d dropped it in manually.

Everything from step 2 onward happens with no further input from you. Steps 1 stays manual by design, you’re still the one deciding what belongs in your library, the automation only handles the mechanical work of getting it there correctly formatted.

Quality profiles: the setting most people configure wrong the first time

A quality profile tells Sonarr or Radarr which resolutions and encodes are acceptable, and in what preference order. The trap most new users fall into is setting the profile too narrow (only accepting one exact quality, so nothing is ever found) or too loose (accepting anything, including a low-quality initial grab that gets replaced constantly). Two settings matter more than the rest:

• Cutoff. The quality level at which the app stops looking for anything better. Set this to whatever you’ll actually be satisfied keeping long-term, not the maximum theoretical quality, since anything above the cutoff still triggers upgrade searches that cost bandwidth and indexer API calls for a difference you may not notice on your actual display.
• Upgrade allowed. Whether the app should replace an already-downloaded file with a better one if a higher-quality release shows up before the cutoff is hit. This is genuinely useful when you want to grab something immediately in a lower quality and quietly upgrade it later, but it does mean a file can change out from under you without you asking for it that specific time, worth knowing before you assume every file is final the moment it lands.

Start with one clear cutoff per profile (something like “1080p, stop there”) rather than trying to hand-tune a complex ranked list of formats and codecs on day one. You can layer in encoder or source preferences later once you understand what your indexers actually tend to offer.

The Docker detail that determines whether this works well or badly: path mapping

This is the single most common setup mistake, and it’s worth understanding before you deploy anything, not after. When Sonarr/Radarr finish a download, they don’t want to physically copy the file from your downloads folder into your library folder if they can avoid it. On the same filesystem, they instead create a hardlink, a second directory entry pointing at the same underlying data on disk. The file exists in both places instantly, with zero additional disk space used and zero copy time, no matter how large it is. When the original in the downloads folder is later cleaned up (by your download client’s seeding/retention rules), the copy in your library folder is completely unaffected, it’s not a “copy” in the fragile sense, it’s a second name for the same data.

Hardlinks only work when both paths are on the same filesystem, and in a Dockerized setup, that means the same container-side path, not necessarily the same host path. This is where people get tripped up: if your download client sees its downloads folder as /data/downloads inside its container, and Sonarr sees the same physical directory but mapped as /downloads inside its own container, Sonarr and the download client each think they’re on different filesystems, since neither has visibility into the other’s mount configuration. The result: Sonarr silently falls back to a real copy instead of a hardlink, and now you’re storing every piece of media twice, once in the downloads folder and once in the library, quietly eating disk space you thought you had.

The fix is consistent volume mapping across every container in the stack. Pick one top-level path (a common convention is /data) and mount your actual storage there identically in every container, downloads client, Sonarr, Radarr, and anything else that touches the same files:

services:
  qbittorrent:
    volumes:
      - /mnt/storage:/data
  sonarr:
    volumes:
      - /mnt/storage:/data
  radarr:
    volumes:
      - /mnt/storage:/data

With that in place, /data/downloads and /data/media/tv are the same filesystem from every container’s point of view, even though the host path is identical the whole time, and hardlinking works exactly as intended. This is worth checking on any existing setup, not just a fresh one, if you’ve never confirmed it, run df inside two of your containers and compare the filesystem each path resolves to.

Indexers, VPNs, and staying inside your own risk tolerance

Prowlarr connects to indexers, which fall broadly into public trackers, private trackers (invite-based, usually much higher quality and reliability, but with their own ratio/seeding rules to respect), and Usenet indexers paired with a Usenet provider subscription. Whichever you use, route torrent traffic for this stack through a VPN with a kill switch, most people run this as a dedicated container (Gluetun is the common choice) that the download client’s network traffic is forced through, so a VPN disconnect stops downloads entirely instead of silently falling back to your real IP. Usenet traffic doesn’t have the same exposure profile as torrenting and doesn’t strictly need this, though plenty of people route it through anyway for consistency.

None of this is specific to any particular kind of content. The same stack that automates grabbing a weekly TV episode also automates grabbing Linux ISOs, your own ripped Blu-ray backups pulled from a seedbox, or anything else you have the rights to store, the automation doesn’t care what it’s fetching, it just executes the search-grab-rename-import loop you’ve configured.

Bottom line

Prowlarr centralizes indexer configuration so you set it up once instead of per-app. Sonarr and Radarr do the actual deciding, searching, and importing, driven by quality profiles you should start simple and tune later. The download client does the fetching, and should sit behind a VPN with a kill switch if it’s handling torrent traffic. The one setup detail that separates a stack that works cleanly from one that quietly wastes disk space is consistent container path mapping, get every container agreeing on the same internal path for your storage, and hardlinks do the rest of the work for free.