docker-compose-nas: An Opinionated Docker Stack for a Self-Hosted Media NAS
Simple Docker Compose NAS featuring Sonarr, Radarr, Prowlarr, Jellyfin, qBittorrent, PIA VPN and Traefik with SSL support
At a glance
- What is it?
- AdrienPoupa/docker-compose-nas wires Sonarr, Radarr, Prowlarr, qBittorrent, Jellyfin and Traefik into one Compose file, with qBittorrent's traffic routed through a PIA WireGuard container. It is a configuration repository, not an application, and its value depends on whether your disk layout and network match the author's assumptions.
- Who is it for?
- Adopt this if you already run Docker Engine and Compose V2 on a recent Linux box, you hold a PIA subscription, and you are willing to mirror the author's file layout rather than adapt the Compose file around your own. Do not adopt it if you need a supported product with a release cadence, if you rely on Usenet rather than torrents as the primary path, or if you cannot give the stack a dedicated machine or VM where ports 80 and 443 are free.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: a media NAS assembled from containers, not bought as an appliance
The README opens with the author's own reasoning: after searching for a NAS solution, the conclusion was that a vanilla Linux box running Docker containers covered the requirement. What ships is an opinionated Compose configuration that browses indexers, retrieves media, downloads it through a WireGuard tunnel with port forwarding, and serves the result over Jellyfin. The target reader is someone who already administers a Linux host and prefers editing YAML to configuring a vendor appliance. The repository bundles Sonarr, Radarr, Bazarr, Prowlarr, qBittorrent, Unpackerr, Jellyfin, Jellyseerr, Homepage and Traefik, plus a long list of optional services (FlareSolverr, SABnzbd, AdGuard Home, Calibre-Web, Decluttarr, Tandoor, Joplin, Home Assistant, Immich, Vaultwarden, Paperless-ngx). That breadth is the point and also the cost: you inherit the author's choices about routing, ports and paths, and the README documents several places where those choices collide with a stock Synology DSM install.
How the pieces connect: one VPN network, one reverse proxy, one dashboard
The architecture visible in the README is a set of containers sharing a Docker network, with qBittorrent attached to the PIA WireGuard container's network namespace rather than the host's. The VPN container is thrnz/docker-wireguard-pia, described as encapsulating qBittorrent traffic in PIA over WireGuard with port forwarding enabled. That port forwarding matters for torrent reachability; without it, inbound peers cannot connect to you. Traefik terminates TLS and routes by path prefix, which is why the application table lists URLs like /sonarr, /radarr, /prowlarr and /jellyfin rather than hostnames. Jellyseerr is the exception, addressed through a $SEERR_HOSTNAME variable. Certificates come from Let's Encrypt, and the README adds a Tailscale path for reaching the stack from outside without exposing it. Homepage sits at / as the dashboard. Note the deliberate image pin on qBittorrent: linuxserver/qbittorrent:libtorrentv1, with the table stating it uses Libtorrent 1.x. That is a version choice baked into the configuration, and anyone who swaps it for the default tag changes behaviour the rest of the stack was tuned around.
Getting it running: environment variables, Compose V2, and the paths you must supply
The stated requirement is any recent Docker-capable Linux box with Docker Engine and Docker Compose V2. The author runs Ubuntu Server 22.04 and reports testing on a Synology DS220+ with DSM 7.1, with a dedicated Synology Quirks section covering that platform. The Quick Start section is where the concrete steps live, and the Environment Variables section defines the values you fill in before the first `docker compose up -d`. The README does not reproduce the full variable list in the material available here, so treat that section as the checklist rather than guessing names. What is documented in detail is the layout the *arr applications expect: a File Structure subsection under Sonarr, Radarr and Lidarr, and a separate section titled Use Separate Paths for Torrents and Storage. That second section is the load-bearing one. If downloads and the media library are on different filesystems, the stack falls back to copying files instead of hardlinking or moving them atomically, which changes both disk usage and how quickly imports complete. The README also documents a Download Client subsection for wiring qBittorrent into Sonarr and Radarr, a Prowlarr section for indexer aggregation, and a Cross-Seed section. Two optional toggles are worth flagging because they alter the network topology: using the VPN for the *arr apps themselves, and running AdGuard Home with DHCP or as a DNS server exposed through Tailscale.
Where the configuration fights your machine: Synology, ports 80 and 443, and port 1900
The Synology Quirks section is effectively a list of failure modes, and it is the most honest part of the README. Free Ports 80 and 443 covers reclaiming those ports from DSM so Traefik can bind them. Free Port 1900 covers a conflict on the SSDP port. There is a Synology DHCP Server and Adguard Home Port Conflict entry, and a User Permissions entry, and a separate note on installing Synology WireGuard. Read together, these say something specific: the default configuration assumes a host where nothing else claims 80, 443 or 1900, and a stock NAS does claim them. The same logic applies to any machine already running a web server or a DLNA service. A second constraint is documented under Laptop Specific Configuration, which implies the author has run this on hardware that suspends and changes networks. If your host is not always on, the VPN container's tunnel and the port-forwarding lease are the parts most likely to need attention after a resume. Finally, the repository has no releases retrieved and no homepage listed, and the licence is not stated in the material available. If you fork it into anything you distribute, resolve the licence question first; nothing here tells you the terms.
The VPN model is the strongest design decision and the hardest to debug
Routing qBittorrent through thrnz/docker-wireguard-pia rather than running a VPN client on the host is the choice that makes this configuration worth reading. It keeps the tunnel scoped to one container, so a VPN drop does not take Jellyfin or Traefik with it, and it lets the *arr apps talk to qBittorrent over the shared Docker network without exposing the client to your LAN. The trade-off is diagnostic. When downloads stall, the fault could be the PIA credentials, the WireGuard handshake, the forwarded port, the indexer, or the *arr-to-qBittorrent connection, and each of those lives in a different container. The README's Optional: Using the VPN for *arr apps subsection extends the tunnel to the indexer managers as well, which is a meaningful change in blast radius: those containers then depend on the tunnel for metadata and indexer queries, not just for torrent traffic. There is no health-check or watchdog described in the material. Port forwarding through PIA is also the part most sensitive to the provider's side of the connection, and the README does not describe a fallback when the forwarded port is not granted.
How it differs from running the same containers by hand or from a managed NAS OS
The obvious alternative is assembling the same containers yourself from the linuxserver images and the official Traefik documentation. That gives you control over the network topology, the path mapping and the image tags, and it costs you the cross-service wiring this repository has already done: Prowlarr feeding Sonarr and Radarr, Unpackerr watching for archives, Bazarr pulling subtitles, Jellyseerr handling requests, Homepage as the entry point. A second alternative is a NAS operating system with an application catalogue, or a media-focused distribution that packages these tools behind a UI. Those give you upgrades and support in exchange for less control over the download client's network path; routing a specific container through a third-party VPN with port forwarding is exactly the kind of thing an appliance-style interface tends to abstract away or forbid. The distinction that matters here is that docker-compose-nas is a configuration, not a product. There is no release artefact to upgrade, no changelog retrieved in the material, and no versioning scheme. You track upstream by pulling images and re-reading the README, which means an upstream image change can alter your stack without any signal from this repository.
Maintenance cost: image churn, no releases, and an unstated licence
Because there are no releases, the maintenance model is continuous rather than periodic. The Compose file pins at least one image tag deliberately (qBittorrent on libtorrentv1), and the rest are referenced through the linuxserver and other upstream namespaces. Pulling newer images is how you get fixes, and it is also how a working stack breaks. The realistic routine is to snapshot the Compose file and the config volumes before a pull, then verify that qBittorrent still connects to the *arr apps and that the VPN container still holds its forwarded port. The optional services multiply that surface: AdGuard Home with DHCP enabled is a DNS server for your network, so a failed upgrade there affects more than your media library, and Immich, Vaultwarden and Paperless-ngx each carry their own data and migration behaviour. On licensing, the material does not state a licence for this repository. That is a gap you should close before redistributing a modified copy, and it is a question for the repository owner rather than something to infer from the dependencies, which carry their own licences.
Who should deploy this, and what to check before the first compose up
This suits an engineer who wants a working media stack on a dedicated Linux host or VM, holds a PIA subscription, and is comfortable treating the Compose file as a starting point to be edited. It suits someone who values the pre-wired integration between Prowlarr, Sonarr, Radarr, qBittorrent and Jellyfin more than they value a supported upgrade path. It does not suit anyone who needs a vendor to answer for breakage, anyone whose primary download path is Usenet rather than torrents (SABnzbd appears only as an optional service, while the VPN and port-forwarding machinery is built around the torrent client), or anyone who cannot free ports 80, 443 and 1900 on the host. The Synology Quirks section exists precisely because a stock DSM install fails those port checks. Before deploying, confirm three things: that your Docker Engine is current enough for Compose V2 as the README requires, that your download directory and media library share a filesystem so the documented hardlink and atomic-move behaviour applies, and that the Environment Variables section lists every value your chosen optional services need, since enabling AdGuard Home with DHCP or extending the VPN to the *arr apps changes the network contract rather than just adding a container.
Editorial conclusion
Adopt this if you already run Docker Engine and Compose V2 on a recent Linux box, you hold a PIA subscription, and you are willing to mirror the author's file layout rather than adapt the Compose file around your own. Do not adopt it if you need a supported product with a release cadence, if you rely on Usenet rather than torrents as the primary path, or if you cannot give the stack a dedicated machine or VM where ports 80 and 443 are free. Before deploying, read the Environment Variables and File Structure sections and check that your download directory and media directory sit on the same filesystem, because the documented hardlink and atomic-move behaviour depends on that and nothing in the Compose file enforces it.
Community notes