Somewhere between “I’ll just self-host a couple of things” and “why is my Kubernetes cluster running a VPN, a torrent client, and six database-backed automation services,” there is a media stack. This is how I built a fully-automated, request-to-playback media pipeline on a homelab Talos/Kubernetes cluster — and, more usefully, the specific things that don’t work the way the tutorials imply.

The cast

The pipeline is the usual “*arr” suspects, each doing one job, all talking to each other over in-cluster DNS:

Prowlarr — indexer manager; one place to configure trackers, syncs them to everything else.
Sonarr / Radarr / Lidarr / Readarr — the automation brains for TV, movies, music, and books. Each watches for wanted releases and hands them off to the downloader.
qBittorrent — the actual download client, living behind a VPN (more on that below).
Jellyfin — the media server that transcodes and streams it all.
Jellyseerr — the pretty front door where you request “add this show,” which fans out to Sonarr/Radarr.
Flaresolverr (a Cloudflare-challenge solver for indexers) rounds it out.

One volume to rule them all (because of hardlinks)

The single most important architectural decision is that the download directory and the media library live on one shared ReadWriteMany volume, mounted at the same path (/data) by every consumer. This is not laziness — it’s what makes atomic, instant imports work.

When a download finishes, Sonarr/Radarr “import” it into the library. If the download and library are on the same filesystem, that import is a hardlink: the file appears in the library instantly, costs zero extra disk space, and the original stays seeding in the torrent client. Split them across two volumes and every import becomes a full copy — double the disk, slow, and your ratio suffers because the seeding copy and the library copy diverge. So: one volume, hardlinks: on, matching mount paths everywhere. Get this wrong and everything works, it’s just quietly wasteful.

Postgres, not SQLite

Each *arr app ships with SQLite by default, and SQLite on NFS is a well-known source of pain — file locking over NFS is fragile, and under load the apps’ health endpoints would stall for 20+ seconds, long enough for a default readiness probe to eject the pod. So the whole stack runs on a shared PostgreSQL instead, with a twist: each app gets its own databases. Sonarr, Radarr, Prowlarr, and Lidarr each want a -main and a -log database; Readarr, uniquely, also demands a third -cache database or it crashes on boot with a cryptic 3D000: database does not exist.

The VPN sidecar, done fail-closed

qBittorrent’s traffic must never leave the cluster except through the VPN. The clean way to do this on Kubernetes is a Gluetun sidecar that owns the pod’s network namespace, with qBittorrent sharing it. A few details make it actually safe rather than just “usually safe”:

Gluetun runs as a native sidecar (an init container with restartPolicy: Always), and qBittorrent has a startup probe that only passes once the tunnel is up. So qBittorrent literally cannot start until the VPN is connected — fail-closed by construction, not by a hopeful readiness check.
Gluetun’s built-in firewall is a kill-switch: if the tunnel drops, all non-VPN egress is dropped, not leaked.
A tiny port-sync sidecar pins qBittorrent’s listen port to whatever port the VPN provider forwards, so incoming connections (and seeding) actually work. It calls qBittorrent’s API from inside the pod.

Two Kubernetes-specific gotchas here. First, Gluetun needs NET_ADMIN to bring up the tunnel interface, and Talos’s default PodSecurity level is baseline, which forbids it — the namespace has to be labeled privileged or the pod is rejected at creation time (and a server-side dry-run won’t warn you; PodSecurity only rejects on the real create). Second, qBittorrent’s WebUI API has no localhost auth bypass — 127.0.0.1 gets you a Forbidden. The trick is its AuthSubnetWhitelist: whitelist the pod CIDR, and any in-cluster caller (the port-sync sidecar, or a quick kubectl exec from another pod) authenticates automatically without a password.

Wiring it together, via API

The post-deploy “connect everything to everything” step is tedious in the UI and delightful over the REST APIs. A recurring pattern: drive each app’s API by kubectl exec-ing into a different media pod and curling the in-cluster service DNS — the *arr container images ship curl but not much else. A few field-name traps will waste your afternoon otherwise: Readarr’s qBittorrent category field is called musicCategory (it inherited Lidarr’s schema), and Sonarr v4 dropped language profiles entirely so you pass activeLanguageProfileId: 1. Jellyseerr’s first-run owner bootstrap wants the full Jellyfin host details, but every subsequent login must send only username and password or it 500s. When in doubt, ask the app for its own /schema.

The failure mode you’ll actually hit

Everything above is setup. The thing that will page you months later is the VPN quietly wedging. Gluetun latches onto a specific provider endpoint, and if that server gets flaky, its internal “restart the VPN” loop can get stuck — the control API reports status: stopping forever, the public IP goes blank, and because it’s fail-closed, qBittorrent has no connectivity at all (safe, but dead). The healthcheck logs an alarming operation not permitted on a DNS lookup, which looks like a firewall bug but is really just the kill-switch doing its job while the tunnel is down.

The fix is refreshingly dumb: restart the whole pod. Gluetun’s own VPN-restart can’t recover from the wedged state, but a fresh container picks a new endpoint and reconnects cleanly — healthcheck green, real VPN IP, port forwarding restored, in about fifteen seconds. It’s a good reminder that “restart the process” and “restart the container” are different blast radii, and sometimes you need the bigger hammer.

Where it stands

The whole stack is GitOps-managed and, as of a recent storage migration, its Postgres databases live on clean, per-UID-owned NFS rather than the old world-writable share. The one piece still on the legacy storage is the media library itself — a terabyte of files that needs an online pre-sync and a maintenance window to move without breaking those precious hardlinks, which is a project for another quiet weekend.

If there’s a theme, it’s that a media stack is less about any single app and more about the connective tissue: shared volumes so imports are free, a fail-closed network namespace so nothing leaks, per-app databases so nothing corrupts, and a healthy respect for the one component (the VPN) that will inevitably be the thing that breaks. Get the tissue right and the rest is just filling in indexer API keys.

The lab journal