Homelab case study · April 2026

Building a VPN-Isolated Media Automation Stack on TrueNAS SCALE

A containerized homelab design using Gluetun, qBittorrent, Sonarr, Radarr, Prowlarr, FlareSolverr, and Jellyfin to separate download traffic from the rest of the NAS and automate media-library workflows.

Platform TrueNAS SCALE · Docker Compose · Dockge

VPN layer Gluetun · WireGuard

Automation Sonarr · Radarr · Prowlarr

Media Jellyfin

6 services VPN, downloader, automation, index management, proxy, and media serving

Shared network namespace Selected containers route through the Gluetun network stack

Persistent storage Configuration and media paths remain outside ephemeral container filesystems

Case study

01Overview 02Stack 03Prerequisites 04Deployment 05VPN layer 06Integration 07Storage 08Security 09Lessons

01 · Project overview

Separate network concerns instead of letting every container talk directly to the internet.

The objective of this homelab project was to create a clean media-automation stack on TrueNAS SCALE while keeping selected outbound traffic behind a dedicated VPN network layer. Rather than giving each service its own independent network path, the design uses Gluetun as the shared network namespace for the containers that need that path.

Sonarr and Radarr handle media-library automation, Prowlarr centralizes indexer configuration, qBittorrent performs downloads, and Jellyfin consumes the completed media files from persistent datasets. The focus of the design is service separation, predictable storage paths, and controlled network behavior.

Use this architecture only for content and services you are legally authorized to access, download, or distribute. A VPN changes the network path; it does not change copyright, licensing, or acceptable-use obligations.

02 · Application stack

Each service has a narrow role.

01

Gluetun

Provides the VPN client and network namespace used by selected containers.

VPN / Network

02

qBittorrent

Download client whose network traffic is routed through the Gluetun service.

Downloader

03

Sonarr

TV-library automation and file organization.

Automation

04

Radarr

Movie-library automation and file organization.

Automation

05

Prowlarr

Centralized indexer configuration and synchronization with supported automation tools.

Indexer Management

06

Jellyfin

Consumes the organized media library from the TrueNAS datasets and serves it to approved clients.

Media Server

TrueNAS SCALE ├── Persistent datasets │ ├── /config │ ├── /downloads │ └── /media │ ├── Gluetun │ ├── qBittorrent │ ├── Sonarr │ ├── Radarr │ └── Prowlarr │ └── Jellyfin └── Reads organized media datasets

03 · Prerequisites

Get storage, permissions, and remote access decisions right first.

TrueNAS SCALE Installed and reachable on the local network.

Storage pool Dedicated datasets created for configuration, downloads, and media.

Container manager Dockge or another Compose-capable deployment workflow.

VPN account A provider/account that supports the protocol and features required by your own lawful use case.

Secrets handling Private keys, passwords, and tokens must never be committed to public posts or repositories.

04 · Deployment model

Compose keeps the network dependency explicit.

The important Compose pattern is that selected containers use Gluetun's network namespace. This keeps the VPN routing decision centralized instead of duplicating VPN configuration across every application.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add:
      - NET_ADMIN
    environment:
      - VPN_SERVICE_PROVIDER=<provider>
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=<secret>
    ports:
      - "8081:8080"   # qBittorrent
      - "8989:8989"   # Sonarr
      - "7878:7878"   # Radarr
      - "9696:9696"   # Prowlarr

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    network_mode: service:gluetun
    volumes:
      - /mnt/Pool/config/qbittorrent:/config
      - /mnt/Pool/media:/downloads

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    network_mode: service:gluetun

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    network_mode: service:gluetun

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    network_mode: service:gluetun

The snippet above is intentionally sanitized. Replace placeholder values with your own provider settings and local paths. Keep secrets outside public code and review current container documentation before deployment.

01

Create the persistent datasets.

Separate configuration, download, and media storage before launching the stack.

02

Deploy Gluetun first.

Confirm the VPN service can establish its tunnel before depending applications are started.

03

Attach dependent containers to the shared network namespace.

Use `network_mode: service:gluetun` only where that network path is actually required.

04

Publish only the management ports you need.

Expose the web interfaces through Gluetun's port mappings rather than duplicating mappings on each dependent service.

05

Validate before automation.

Confirm application reachability, DNS, storage access, and VPN routing before connecting the services together.

05 · VPN layer

WireGuard keeps the network layer lightweight.

I used WireGuard for this build because it is efficient and well suited to a low-power homelab host. The exact VPN-provider variables depend on the provider and may change over time, so the current provider and Gluetun documentation should be treated as authoritative.

Setting	Purpose
VPN service provider	Selects the provider-specific connection logic used by Gluetun.
VPN type	Chooses WireGuard or another supported protocol.
WireGuard private key	Authentication secret. Never publish it.
WireGuard address	Address assigned to the tunnel interface by the provider.
Outbound LAN subnet	Allows only the required local-network communication where the design needs it.

Do not describe a VPN as making activity “invisible” or “anonymous.” It changes who can observe different parts of the traffic path, but the VPN provider, applications, destination services, account identifiers, and endpoint configuration can still matter.

06 · Application integration

Connect the services only after each one works independently.

01

Connect Prowlarr to Sonarr and Radarr.

Use each application's API key and the internal service address available within the shared network namespace.

02

Configure supported index sources.

Use sources you are legally permitted to access and that comply with the relevant service terms.

03

Add qBittorrent as the download client.

Point Sonarr and Radarr to the qBittorrent WebUI endpoint exposed through Gluetun.

04

Set consistent root folders.

Make sure the same physical dataset is mapped consistently across downloader, automation, and media-server containers.

07 · Storage paths

Path consistency matters more than the application names.

The downloader, automation tools, and Jellyfin all need to agree on where completed media is stored. Inconsistent host/container path mappings are a common source of failed imports and duplicate copies.

Purpose	Example host path	Example container path
Downloads	/mnt/Pool/media/downloads	/downloads
Movies	/mnt/Pool/media/Movies	/media/Movies
TV	/mnt/Pool/media/TV	/media/TV
Jellyfin library	/mnt/Pool/media	/media

08 · Security and operational notes

The stack is safer when secrets, routing, and exposure are explicit.

Private keys Keep VPN keys and credentials out of public Compose files, screenshots, and repositories.

VPN failure behavior Test the actual container firewall behavior in your deployed version rather than relying on assumptions about “kill switch” semantics.

Local network access Permit only the LAN subnets that dependent services genuinely require.

Published ports Expose only the management interfaces needed on trusted networks.

Updates Pin or review image versions deliberately and back up configuration before significant changes.

Content rights Use automation tools only with media and sources you are authorized to access.

09 · Lessons learned

The architecture is easier to troubleshoot when every dependency is visible.

01

Centralize the network path.

One VPN container is easier to reason about than independent VPN configuration in every application.

02

Keep storage mappings consistent.

Most automation failures become easier to diagnose when every service sees the same underlying dataset in a predictable way.

03

Test failure modes, not just the happy path.

Stop the VPN service, restart containers, break DNS intentionally in the lab, and verify that the resulting behavior matches your security expectations.

04

Do not publish secrets or private management details.

A good case study explains the architecture without exposing keys, internal credentials, or unnecessary administrative endpoints.

Related work

Part of the same TrueNAS homelab environment.

TrueNAS Home Server → The underlying storage and application platform used for this lab. Snipe-IT on TrueNAS → A separate self-hosted application deployment on the same environment.

TrueNAS SCALE Gluetun WireGuard qBittorrent Sonarr Radarr Prowlarr Jellyfin Docker Compose Homelab