The Arr Stack: The Decisions That Determine How It Runs, Not Just Whether It Runs
You've decided to run the arr stack. The container list is chosen — Sonarr, Radarr, a download client, probably Prowlarr. What you decide in the next few hours determines whether this stack runs reliably for the next two years or becomes a system that mostly works until it doesn't, and nobody's quite sure why.
These aren't decisions about which apps to include. Those are made. These are the decisions that sit between a working docker-compose.yml and a stack you actually trust.
Download protocol: Usenet, torrents, or both
This decision shapes more downstream configuration than any other. It determines which indexers you need, what the download client looks like, and where the most common handoff failures will occur.
Usenet requires a paid provider account and at least one paid indexer subscription. NZBGet or SABnzbd handles the client side. The integration with Sonarr and Radarr is clean — files arrive quickly, the arr apps monitor the download folder and execute the rename and move with minimal friction. The cost is ongoing: provider subscription, indexer access, sometimes both. The return is reliability. Usenet articles are either there or they're not. When they're there, the download completes. There's no seeding obligation, no swarm health dependency, no waiting on peers.
Torrents are free to enter. qBittorrent or Deluge on the client side, public or private indexers accessed through Prowlarr. The arr app integration is slightly more complex — seeding ratios need to be tracked, the download client needs to know when it's safe to move a completed file versus still seeding it, and private tracker availability varies. For a single user with tolerance for some manual oversight, this works. For a multi-user setup where others expect content to appear on request, Usenet's reliability advantage starts to matter more.
Running both covers gaps in each ecosystem. It also doubles the download client surface area and the indexer management overhead. In a casual homelab context, both is workable but adds maintenance debt. In a context where someone else's expectations are on the line, Usenet as the primary source with torrents as fallback is a more defensible posture than the reverse. Decide which scenario you're actually in before configuring anything else.
Path mapping: the configuration that makes or breaks everything
This is the single most consequential configuration decision in the stack. Get it wrong and the arr apps will report success while nothing actually happens. Get it right and you rarely think about it again.
The requirement: every container that touches the same file must reference it through a consistent path, even if the Docker bind mounts use different host paths. Sonarr, NZBGet, and your media server all need to operate with the same understanding of where files live — even if their internal view looks different from the outside.
The cleanest approach for homelab: a single volume on the host that contains both your download staging area and your media library, mounted into every container under a shared path prefix. /data on the host becomes /data inside Sonarr, inside NZBGet, inside Jellyfin. Downloads land in /data/downloads/complete. Sonarr moves completed files to /data/media/tv. Because all containers see the same /data, the handoff works without translation. On a single filesystem, Sonarr's move operation can use hardlinks — the file isn't copied, just linked, which means the rename and move is instant and costs no additional disk space while the download client finishes seeding.
Where this gets harder: when the download volume and the media volume sit on different physical drives or different NAS shares, mounted separately into each container. Now the move is a cross-filesystem copy rather than a hardlink — slower, and the mapping between download paths and media paths has to be configured explicitly in each arr app. This works. Many setups run exactly this way. Understand the tradeoff upfront rather than discovering it after configuring six containers and wondering why imports are slow and storage is doubling.
For a serious homelab with multiple users waiting on content: consolidate to a single volume if the hardware supports it. The reduction in path complexity is worth more than the flexibility of separate mounts. For a casual personal setup where import speed doesn't matter: separate mounts work, just be explicit about the mapping in each app.
Indexer management: Prowlarr or per-app configuration
Prowlarr is the right answer for almost every setup. It manages indexer configuration centrally and syncs automatically to Sonarr and Radarr. Adding a new indexer means one configuration, not four. Removing a failing indexer means one change, not four. When an indexer rotates its API key, you update it once.
The per-app approach — configuring indexers separately in each arr app — was the original model and still functions. It gives more granular control over which indexers each app uses, which occasionally matters if Sonarr and Radarr genuinely need different indexer profiles. That use case is uncommon. In most setups, per-app configuration just means more surface area to maintain and more places to update when something changes.
Start with Prowlarr. Diverge only if you encounter a specific reason to — and you'll know you have that reason before you set it up. The maintenance savings are immediate and the control you give up is theoretical for most deployments.
Seerr: who is this stack actually serving
Jellyseerr or Overseerr adds a request management layer. The decision to include it isn't technical — it's about what the stack is for and who it's for.
If this is a single-user personal system, Seerr adds a container that duplicates functionality you already have direct access to in Sonarr and Radarr. You're adding a request UI for a workflow that doesn't involve requests. Skip it, and come back if circumstances change.
If other people use your media server and make requests, Seerr changes the operating dynamic significantly. Without it, requests arrive through whatever channel people happen to use — and you handle them manually in the arr apps. With it, requests route through an interface that integrates with Sonarr and Radarr, auto-approves what you've decided should auto-approve, and queues everything else. The operational benefit is directly proportional to the number of people making requests and inversely proportional to how much you want to be the IT desk for your household.
The lens here isn't homelab versus enterprise — it's single user versus shared service. If you're running a shared service, Seerr earns its container immediately. If you're the only user, it doesn't.
Tautulli: visibility or overhead
Tautulli surfaces playback statistics — what was watched, by whom, when, and how much of it. It answers the question the arr stack itself cannot answer: is the library being used, or is it growing on its own momentum?
The decision to include it depends on what you'll actually do with that information. Tautulli's value isn't in observation for its own sake — it's in what the observation prompts. If you'll review usage periodically and act on it — pruning unwatched content, adjusting quality profiles based on what gets watched versus accumulated, reconsidering whether certain acquisition rules are serving your actual habits — Tautulli earns its container. If the data surfaces and nothing changes in response, it's observability without a feedback loop.
For a serious homelab or shared service context: run it. The gap between what gets downloaded and what gets watched is usually larger than expected, and knowing that gap exists changes how you think about configuring the acquisition side. For a casual single-user setup where the library is intentional and modest: optional, and there's no shame in skipping it.
What to settle before the first container starts
The arr stack's configuration decisions have an order that matters. Download protocol shapes everything downstream — don't configure the arr apps before deciding this. Path mapping is the most common source of silent failure — establish the layout before anything else, because wrong path mapping produces problems that look like arr app problems but trace back to a volume mount. Indexer management is worth standardising on Prowlarr unless there's a specific reason not to. Optional layers earn their place based on what the stack is serving, not on principle.
The questions worth sitting with before the first docker compose up: Who is this stack for, and what do they expect from it? Where is your storage, and can it support a single-volume layout? Are you running Usenet, torrents, or both — and are you honest about the ongoing maintenance commitment each requires?
The arr stack rewards time spent on these decisions before configuration begins. The failure modes it produces when these decisions are deferred surface at the worst moments — after everything appears to be running, when something quietly stops working and the cause is three layers back in a path mapping decision that seemed fine at the time and wasn't.
