The *arr Media Automation Stack

Last reviewed Oct 11, 2026 · 648 words

The *arr stack works when every app agrees on one folder tree and breaks when they don't. Give qBittorrent, Sonarr, Radarr and Bazarr the same /data mount, deploy the download client first and the request portal last, and the whole seven-app pipeline fits in about 1,324 MB of RAM by the directory's estimates. Most of that is Jellyfin and Jellyseerr at 512 MB each; the automation apps in the middle are listed at 50 to 100 MB apiece.

What talks to what

Requests flow left to right, and every arrow is an API key pasted from one app's settings into another's.

Jellyseerr is the front door. Users sign in with their Jellyfin accounts, browse, and click request; Jellyseerr hands movies to Radarr and series to Sonarr. Those two hold the library logic: what is wanted, which quality profile applies, when to upgrade. They search for releases through indexers, and this is where Prowlarr earns its place. You add each indexer once in Prowlarr, register Sonarr and Radarr as applications there, and Prowlarr pushes the indexer list into both and keeps it in sync. Without it you maintain the same indexers twice.

When Sonarr or Radarr pick a release they send it to qBittorrent, usually tagged with a category per app so each one only imports its own downloads. After the download finishes, the *arr app imports, renames and files it into the library, then tells Jellyfin to rescan. Bazarr watches Sonarr and Radarr through their APIs and fetches subtitles for whatever lands. Jellyfin streams the result.

Deploy in this order

The directory rates Radarr and Bazarr Medium and the other five Easy. Jellyfin's own transcoding and remote access questions are covered in the Jellyfin setup guide.

Why do imports copy files instead of moving them?

Because the download client and the arr apps see different mounts. If qBittorrent writes to /downloads and Radarr manages /movies as two separate volumes, the kernel cannot hardlink across them, so every import becomes a full copy and your disk briefly holds two of each file. The catalogue's own deploy note for both Sonarr and Radarr says it plainly: one shared /data mount for the arr app and the download client, with torrents and media as subfolders inside it. Then imports are instant hardlinks, seeding continues from the same blocks, and nothing doubles. This is the single most common mistake with this combination, and fixing it later means moving the whole library.

The related trap is path mismatch. If qBittorrent reports a file at one path and Sonarr expects another, imports fail silently. Use identical container paths everywhere rather than remote path mappings.

Shared concerns: proxy, auth, backups

Only Jellyfin and Jellyseerr need to face users. Keep Sonarr, Radarr, Prowlarr, Bazarr and qBittorrent on the LAN or behind a VPN; they hold API keys to each other. If you proxy Jellyfin, enable websocket pass-through or the dashboard and SyncPlay break. Back up each app's /config folder, not the media: the configs hold your quality profiles, indexer list and request history, and they are small.

What I'd do

Lay out the /data tree before starting a single container, follow the order above, and wire Prowlarr to both arrs on day one. The arr stack explainer goes deeper on quality profiles, and Sonarr and Radarr are where most of your tuning time will go.