Sonarr

Last reviewed Aug 25, 2026 · 659 words

Sonarr automates a TV library: tell it which series you follow, and it finds releases via your indexers, hands them to your download client, renames the result to a clean Series/Season 01/ layout, and upgrades quality when better versions appear — forever, unattended. It's the piece that turns media self-hosting from a weekly chore into plumbing. It is also the app whose filesystem layout decision, made in the first ten minutes, determines whether your disk enjoys instant imports or years of pointless copying.

The one decision that matters: a single /data mount

The canonical mistake is giving Sonarr and the download client separate volume mounts (/downloads and /tv from different host paths). Docker then presents them as different filesystems, so every completed download gets copied into the library — doubling disk churn and leaving torrents unseedable. The fix is structural: one shared mount for everything.

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    ports:
      - "8989:8989"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - ./config:/config
      - /srv/data:/data
    restart: unless-stopped

With the host's /srv/data containing both downloads/ and media/tv/, and every arr and download container mounting that same /data, imports become instant hardlinks: the file appears in the library while the original keeps seeding, costing zero extra bytes. Set this before adding your first series — restructuring a populated library later is an afternoon of path surgery. The same layout serves the whole arr stack (Radarr for movies, and Prowlarr managing indexers for all of them so you configure each indexer exactly once).

Quality profiles: decide once what "good enough" means

Sonarr's default profiles will happily re-download your entire library each time a marginally better release appears. Tame it in five minutes: pick one profile (1080p WEB-DL is the sane household standard — good quality, sensible sizes, no HDR complications), set a quality ceiling as well as a floor, and use the cutoff so upgrades stop once the target is met. Size limits per quality catch the pathological releases. If storage is the constraint, remember the honest math: a tracked series at 1080p runs 2–5 GB per season for WEB-DL, and Sonarr will faithfully fill whatever you let it — the monitoring stack watching disk-space trend earns its keep here.

Series settings people learn the hard way

• Monitor "future episodes" when adding an ongoing series you're current on — the default of grabbing the entire back catalogue at 3 a.m. is the classic bandwidth surprise.
• Season folders on, always — Jellyfin and every scanner expect them.
• Sonarr uses TheTVDB's episode ordering; anime and reordered shows sometimes mismatch releases. The series-edit page's "series type" (standard/daily/anime) fixes most of it.
• Let Sonarr do all renaming. If you also hand-organise, the two of you will fight, and Sonarr is more persistent than you are.

Keep the whole thing off the internet

Sonarr's web UI has authentication, but its API, its connected download client, and its indexer credentials make the stack a poor thing to expose. There's no reason to: you interact with it rarely (that's the point), and remote requests are better served by putting Jellyseerr in front — the household asks for shows in a friendly UI, Sonarr executes silently. Everything else stays LAN or Tailscale-only, per the standard threat-model logic.

What I'd do

The single /data layout from minute one, Prowlarr feeding indexers, 1080p WEB-DL profile with a cutoff, future-episodes monitoring, Jellyseerr as the family's front door, all of it tailnet-only. Configured this way, Sonarr is the most set-and-forget service in the rack — the entire point of the arr philosophy — and the only ongoing interaction is your household wondering how new episodes keep appearing before they've thought to ask.