"The *arr stack" is shorthand for a family of open-source tools that automate finding, downloading, renaming and organising media. Point them at a torrent or Usenet client and a media server, and new episodes appear in your library the morning after they air — without you touching anything.
What each app actually does
| App | Job |
|---|---|
| Prowlarr | Manages your indexers and trackers in one place, and pushes them to the others. Set a tracker up once here instead of five times. |
| Sonarr | TV. Tracks the shows you follow, watches for new episodes, picks the best release that matches your quality rules. |
| Radarr | The same thing for films. |
| Bazarr | Finds and downloads subtitles for whatever Sonarr and Radarr bring in. |
| Jellyseerr | A request page. Lets you (or family) ask for a title, then hands it to Sonarr or Radarr. |
They are not a monolith — each is a separate service with its own web UI, talking to the others over local HTTP APIs.
How the pieces connect
The flow is always the same, whichever apps you use:
Jellyseerr → someone requests a title
↓
Sonarr/Radarr → decides what release to get
↓
Prowlarr → searches your indexers
↓
qBittorrent → downloads it (or SABnzbd for Usenet)
↓
Sonarr/Radarr → renames + moves it into the library
↓
Bazarr → fetches subtitles
↓
Jellyfin/Plex → scans and it appears, ready to watchEvery arrow is a setting you configure once. The apps then run this loop forever without supervision.
The two things that break most setups
1. Inconsistent paths
This causes more broken *arr installs than everything else combined. Your download client and Sonarr must see the same file at the same path.
If qBittorrent saves to /downloads/complete but Sonarr is told the download lives at /data/torrents, Sonarr cannot find the finished file and the import silently fails. In containerised setups this happens constantly because each service has its own view of the filesystem.
The fix is to use a single shared root and mount it identically everywhere:
/data
├── torrents/ ← download client writes here
│ ├── movies/
│ └── tv/
└── media/ ← Sonarr and Radarr move files here
├── movies/
└── tv/2. Losing hardlinks
When Sonarr imports a finished download it can either copy the file into your library or hardlink it. A hardlink is a second name for the same data on disk — it costs no extra space, and it lets you keep seeding the original while the library has its own tidy copy.
Copying instead doubles your disk usage for every single item. On a seedbox with a storage quota, that halves your library for no reason.
Hardlinks only work within the same filesystem. That is exactly why the shared /data root above matters: if torrents and media are on different mounts, Sonarr silently falls back to copying.
If your disk fills twice as fast as expected, you have lost your hardlinks. Check that downloads and library live under one root.
The hard way vs the easy way
Done manually on a bare VPS, this means wiring up six or seven services by hand, getting PUID/PGID right so they can read each other's files, mapping storage consistently, setting up a reverse proxy so each app has a URL, and then debugging permissions when an import fails. It is a genuinely satisfying afternoon if you enjoy that sort of thing — and a miserable one if you do not.
On a Seedbox.ch box the Cresdock panel deploys each app in one click with the paths and permissions already correct, so the shared-root and hardlink problems above simply do not arise. You still get full root on a Rootserver if you want to go deeper or run something outside the catalogue.
A sensible order to set it up
- Download client first. Deploy qBittorrent (or SABnzbd for Usenet) and confirm it saves into
/data/torrents. - Prowlarr next. Add your indexers and trackers here. Test each one.
- Sonarr and Radarr. Point them at the download client, set the root folder to
/data/media, then connect Prowlarr so indexers sync across automatically. - Add one show and one film and watch a full cycle complete before adding more. Almost every misconfiguration shows up on the first import.
- Then Bazarr and Jellyseerr, once the core loop is proven.
- Finally your media server — Jellyfin, Emby or Plex — pointed at
/data/media.
Resist the urge to deploy all seven at once. If something breaks you will not know which layer to blame.
Quality profiles: set them once, properly
The most common regret is leaving quality profiles at their defaults, then discovering your drive is full of 60 GB remuxes. Decide early what you actually want — 1080p is enough for most people, and a sensible cap on file size will save you terabytes.
Set a maximum size per episode or film, prefer efficient codecs, and use Sonarr's upgrade rules deliberately. "Upgrade until best quality" sounds appealing until it re-downloads your entire library.
Common questions
Can I run torrents and Usenet at the same time?
Yes, and it is a common setup. Sonarr and Radarr will happily use both, preferring whichever finds a match first. Add SABnzbd or NZBGet alongside your torrent client.
Do I need a Rootserver, or will a managed box do?
The whole stack deploys from the panel with no terminal on any Rootserver — Terabox or Flashbox — which carries the uncapped catalogue, root, and the freedom to install things outside it. Kilobox and Gigabox are built around a torrent client, FTP and a VPN, so if the *arr stack is what you are here for, start at Terabox 2 from €14.99/mo. The comparison table shows what each plan deploys.
Will this work with Plex as well as Jellyfin?
Yes — the *arr apps do not care which media server you use. Plex, Jellyfin and Emby all deploy in one click on a full-root Rootserver, so you can even run more than one against the same library.