The *arr stack: automating a media library you actually own

The *arr stack has a reputation problem, so let's deal with it in the first paragraph. Sonarr, Radarr, and friends are content-neutral tools — they organize, rename, and track media files — but most guides about them wink at the camera about where those files come from. This one doesn't. This doc is about running the stack for media you actually own: discs you've ripped yourself, home video, DRM-free purchases, and freely licensed content. We don't publish piracy how-tos, and that isn't a disclaimer we were forced to write — a library you own is genuinely the best reason to run this stack. If you were hoping for the other kind of guide, this page will disappoint you.

Why bother automating media you already own? Because a shelf of discs is a terrible user interface. Rip them once and the discs go back in the case forever: nothing gets scratched, everything is searchable, subtitles work, playback resumes across devices, and the whole collection follows you to any screen in (or out of) the house. The stack's actual skills — organizing, renaming, fetching metadata, tracking gaps, serving video — are exactly what a large personal rip library needs.

The cast

Here's the part most guides skip: for an own-media library you need less of this than you think. Jellyfin alone will happily serve a well-named folder tree. Add Sonarr and Radarr as librarians — pointed at an import folder where your rips land — and you get strict renaming, artwork, rich metadata, and a clear view of what's missing from a series you're ripping season by season. Prowlarr and a download client only enter the picture for content that is legal to download in the first place: public-domain film archives, Creative Commons media, and the world's favorite bandwidth test, Linux ISOs.

How the pieces talk

There's no shared database and no message bus. Every app in the stack is a small web server with an HTTP API and an API key, and the "integration" between them is nothing more exotic than REST calls. That's why the stack is so modular — every arrow in the diagram below is an HTTP request you could make yourself with curl.

flowchart TD
  RIPS[Your disc rips] --> DROP[Import folder]
  SEERR[Jellyseerr requests] --> SONARR[Sonarr and Radarr]
  PROWLARR[Prowlarr] -- syncs indexers via API --> SONARR
  SONARR -- sends job via API --> DL[Download client]
  DL -- completed files --> SONARR
  DROP --> SONARR
  SONARR -- rename and hardlink --> LIB[Media library]
  LIB --> JF[Jellyfin]
  SONARR -- rescan webhook --> JF
  JF --> SCREENS[TV, phone, browser]

A few of those arrows deserve a closer look.

Prowlarr is a hub, not a pipeline. You configure your sources once in Prowlarr, and it pushes those definitions to Sonarr, Radarr, and Lidarr through their APIs. No media ever flows through Prowlarr — it's configuration sync.

The download handoff is a polite conversation. When Sonarr wants something (say, a public-domain serial you asked Jellyseerr for), it POSTs the job to the download client's API tagged with a category like tv-sonarr, then polls for status. When the client reports the download complete, Sonarr — not the download client — imports the files: renames them to its naming scheme and places them in the library. Then it fires a webhook at Jellyfin to trigger a library rescan, so the new item appears within seconds instead of at the next scheduled scan.

Docker networking is where first-timers get stuck. The standard deployment is one Docker Compose file with every container on the same user-defined bridge network. On that network, Docker's embedded DNS lets containers reach each other by service name: Sonarr talks to the download client at http://qbittorrent:8080, not localhost:8080. This is the classic first-night failure: inside a container, localhost means that container, so pointing Sonarr at localhost aims it at itself. If you want the full picture of how bridge networks, embedded DNS, and published ports fit together, we have a whole doc on it: Docker in depth.

Note that every port in the table above is internal. None of them should be published to the internet — the only thing that ever needs to be reachable from outside is Jellyfin, and even that shouldn't be a raw port forward (more below).

Paths: where the stack actually breaks

It's not networking, but no honest doc about this stack can skip it, because ninety percent of "Sonarr can't import" errors are path problems wearing a trench coat.

The rule: give every container the same single mount, and structure it underneath.

/data
├── imports        <- your rips land here
├── torrents       <- download client works here
└── media
    ├── movies     <- Radarr's library
    ├── music      <- Lidarr's library
    └── tv         <- Sonarr's library

Mount /data once into every container. Because everything lives on one mount, every container sees one filesystem, and Sonarr can move a finished file into the library with a hardlink — instant, atomic, zero extra disk. Mount imports and media as two separate Docker volumes instead, and the containers see two filesystems: hardlinks become impossible, every import silently degrades to a full copy, and a 40GB remux briefly costs you 80GB. "Remote path mappings" — a setting that confuses everyone — exist only for the case where the download client runs on a different machine and the same folder genuinely has two different paths.

The own-media workflow, start to finish

1. Rip. MakeMKV is the standard tool for getting your own Blu-rays and DVDs onto disk. One honest legal note, because we promised no winking: format-shifting discs you own for personal use is broadly tolerated and feels like plain fairness, but decrypting commercial discs technically intersects with anti-circumvention law (the DMCA in the US), and the rules differ by country. We're not lawyers; know your local situation. Home video, DRM-free purchases (music from Bandcamp, for instance), and public-domain material carry no such asterisk.
2. Drop the rip in the import folder. Sonarr or Radarr picks it up, identifies it, renames it to your naming scheme, files it into the library, and pulls artwork and metadata. This is the moment the stack earns its keep: fifty discs ripped over a weekend become a perfectly organized, fully labeled library with zero manual filing.
3. Optionally transcode. A raw Blu-ray remux is 30–40GB. HandBrake (one at a time) or Tdarr (as an automated pipeline) can shrink your rips dramatically with no visible loss on a living-room TV.
4. Watch. Jellyfin serves the library to every TV, phone, and browser in the house.

Remote access: don't port-forward Jellyfin naked

Wanting your library on your phone away from home is the natural next step, and the wrong answer is forwarding port 8096 to the internet. Your options, in the order we'd recommend them:

• WireGuard or Tailscale. Nothing is exposed at all; your phone joins the home network and streams as if it were on the couch. This is what we run. If your ISP has you behind CGNAT, here's why that breaks inbound connections and what to do — Tailscale handles CGNAT gracefully. For the broader topology picture, see site-to-site vs remote-access VPNs.
• A reverse proxy with TLS and strong authentication, if family members need access without installing a VPN app. More exposed surface, more maintenance responsibility.
• Not Cloudflare Tunnel. Tunnels are great for admin dashboards, but pushing hours of video through the free tier is outside what it's intended for and a good way to get throttled or actioned. Don't build your media access on it.

One last networking trick worth knowing

Even if your download client only ever touches Ubuntu ISOs and public-domain film, you'll see stacks that route it through a VPN container like Gluetun using network_mode: service:gluetun. The mechanism is genuinely interesting: the download client container is started inside another container's network namespace. It has no network identity of its own — its only path to the internet is through the VPN container's tunnel. If the VPN drops, there is no route at all: a kill switch enforced by architecture rather than by firewall rules. It's one of the better practical demonstrations of what Docker networking actually is under the hood.

Bottom line

The *arr stack is a set of librarians and a media server having polite HTTP conversations across a Docker bridge network. For a library you own, you get most of the value from just Jellyfin, Sonarr, Radarr, and a disciplined /data layout — rip your shelves, drop the files in the import folder, and let the robots do the filing.