Deploying the Arr Stack: Getting Path Mapping Right Before Anything Else
The most common arr stack failure mode doesn't surface an error. Sonarr reports the download complete. NZBGet has moved the file. The import job finishes without complaint. Nothing appears in your media server. The problem is path mapping — and it was misconfigured before the first container started. This
The Arr Stack: The Decisions That Determine How It Runs, Not Just Whether It Runs
You've decided to run the arr stack. The container list is chosen — Sonarr, Radarr, a download client, probably Prowlarr. What you decide in the next few hours determines whether this stack runs reliably for the next two years or becomes a system that mostly works until it doesn&
The Arr Stack: Why It Feels Over-Engineered Until It Doesn't
The appeal of running your own media server is straightforward enough. What catches people off guard is the stack that tends to form around it — Sonarr, Radarr, Lidarr, NZBGet, Jellyseerr, Tautulli. Six containers before you've watched a single episode. That count produces a predictable reaction: this is more
OPNsense DHCP — The DNS Handout Decision
DHCP is the mechanism that makes every other DNS decision actually take effect. You can configure Unbound perfectly, deploy AdGuard with a clean compose file, and have a solid filtering policy — and none of it matters if clients are still pointing at whatever the router handed out six months ago.
OPNsense DHCP — Handing Out the Right DNS Servers
DHCP is the part of the DNS stack nobody thinks about until clients are resolving through the wrong server. The filtering is configured, the resolver is running, the host overrides are in place — and clients are still querying 8.8.8.8 because the DHCP server never got updated. This
Unbound on OPNsense — Why the Resolver Lives on the Router
AdGuard is already running. It's filtering queries, logging traffic, handing back clean responses. The question that comes up quickly is: where do the queries AdGuard can't answer locally actually go? And separately — where do internal hostnames resolve? These are two different problems, and collapsing them into
Unbound DNS on OPNsense — Local Resolver and Host Overrides
OPNsense ships with Unbound DNS enabled but barely configured. Out of the box it forwards to whatever system DNS is set, registers no local hostnames, and returns public IPs for services you're running locally. If you're pointing AdGuard — or any other DNS filter — upstream at your
AdGuard Home — Where It Sits in a Layered DNS Stack
AdGuard Home is a DNS filtering proxy. That's the complete description of what it does and what it should be responsible for. The decisions that matter aren't about AdGuard itself — they're about where it sits in your network, what it hands off to, and
AdGuard Home on Docker — Bridge Mode and Upstream DNS
The default AdGuard Home documentation puts it on host networking and walks you through disabling systemd-resolved to free port 53. That's one way to do it. If you're already running a layered DNS stack — an upstream resolver handling local overrides, a reverse proxy managing your internal
AdGuard Home: DNS Filtering as Infrastructure, Not Just a Privacy Tool
AdGuard Home gets introduced to most homelab builders the same way: as a Pi-hole replacement. Better interface, built-in DoH, easier to update. A cleaner implementation of the same idea — filter DNS queries to block ads and trackers at the network level. The framing is a privacy tool with better ergonomics.