Pi-hole & AdGuard Home on Proxmox: Network-Wide Ad Blocking as an LXC
The one-command install, making it your network's real DNS server without breaking anything, and the single-point-of-failure tradeoff worth planning for.
For a lot of people, a DNS-blocking sinkhole is the very first thing they run in a homelab, and Proxmox makes it close to effortless: a 512MB LXC container that blocks ads and trackers for every device on the network, not just the one browser with an extension installed. Pi-hole and AdGuard Home are the two projects that dominate this space, they install almost identically, and both have a proper community script on this site's usual source. This guide covers both, plus the part that actually matters once it's running: pointing your network at it safely.
Pi-hole or AdGuard Home: Pick One
Both are free, open source, and do the same core job: intercept DNS requests and refuse to answer for domains on a blocklist. The differences are in the edges.
- Pi-hole: the more established project, with the larger community and a decade of tutorials to fall back on if something's unclear. Its post-v6 web interface has a dedicated Local DNS section that a lot of people find more straightforward for mapping hostnames like
nas.home.lanto internal IPs. Encrypted upstream DNS (DNS-over-TLS) now needs an extra piece, Unbound or dnscrypt-proxy, running alongside it. - AdGuard Home: built-in support for DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC upstream with no extra service to install, and native per-client rules, so you can apply a stricter blocklist to a kid's tablet than to your own laptop without any extra tooling. The web UI uses a top menu instead of Pi-hole's sidebar; which one reads more clearly is personal preference.
Neither is the "wrong" pick for a home network. If you want the bigger community and simpler local-DNS management, go Pi-hole. If encrypted upstream DNS or granular per-device filtering matters more to you than community size, go AdGuard Home.
Getting It Running
Both projects have a dedicated LXC script from Proxmox VE Helper Scripts, run from the Proxmox host's own shell:
Pi-hole
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/pihole.sh)"
AdGuard Home
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/adguard.sh)"
Both default to a Debian 13 LXC with 1 core, 512MB RAM, and a 2GB disk, which is plenty; DNS filtering isn't demanding work. AdGuard Home also offers a lighter Alpine Linux profile (256MB RAM, 1GB disk) during the script's prompts if you'd rather trim it further. When the script finishes, Pi-hole needs one more command inside the container to set the admin password (pihole setpassword); AdGuard Home walks you through an admin account as part of its own first-run setup wizard in the browser.
One asymmetry worth knowing up front: Pi-hole updates through its own CLI (pihole -up) or by re-running the install script. AdGuard Home can only be updated from inside its own web UI, there's no supported command-line update path, so that's where to check when a new version is available.
Making It Your Network's Real DNS Server
A running container that nothing points to doesn't block anything. Getting from "installed" to "actually filtering every device" is a few deliberate steps, in this order:
- 1. Give the container a static IP first. Set it in the container's own network config (or reserve it in your router's DHCP by MAC address), not left on a regular dynamic lease. Every device on the network is about to be told to trust this exact address; if it changes, DNS breaks for everyone until you update it everywhere.
- 2. Point your router's DHCP-issued DNS server at it. This is the one setting that makes every device on the network use it automatically, with nothing to configure per-device. It's usually under the router's LAN or DHCP settings, labeled something like "DNS Server" or "Primary DNS."
- 3. Only take over DHCP itself if your router won't let you set a custom DNS server. Both Pi-hole and AdGuard Home can run their own DHCP server, but two DHCP servers answering on the same network causes real, confusing problems (devices randomly getting leases from whichever one answers first). If you go this route, disable the router's own DHCP server completely first.
Whichever path you use, add a secondary DNS server in your router's settings, a public resolver like 1.1.1.1 or 9.9.9.9 is fine, as a fallback. If the container is ever down for maintenance or a reboot, the network loses ad-blocking instead of losing DNS resolution entirely, which is a much easier problem to live with for a few minutes.
A Few Things I'd Get Right From the Start
1. Static IP before anything else
Covered above, but it's the step people skip and regret. Set it before you touch router DNS settings, not after.
2. Always keep a secondary DNS resolver configured on the router
A single point of failure for DNS is the real tradeoff of this whole setup. A fallback resolver turns a container outage into a minor inconvenience instead of "the internet is down" for the whole house.
3. Pick one DHCP source, never two
If you decide to let Pi-hole or AdGuard Home hand out DHCP leases, disable the router's DHCP server entirely first. Two answering at once is a confusing class of bug to troubleshoot later.
4. Export your configuration after you've tuned it
Both projects can export their settings and blocklists (Pi-hole via Settings → Teleporter, AdGuard Home from its own backup option). Do this once you've added your own local DNS records or allowlist exceptions, so a container rebuild doesn't mean starting from zero.
5. Take a Proxmox snapshot before a major version upgrade
Same convention as every other guide on this site. This one's especially cheap to follow, the container is tiny, so a snapshot costs almost nothing in disk space.
Related Resources
Official Pi-hole Site
Docs, blocklists, and the project's own install instructions.
Official AdGuard Home Overview
Feature list and docs straight from AdGuard.
Docker on Proxmox & Windows
The alternative path if you'd rather run this (and other apps) inside Docker.
pfSense & OPNsense on Proxmox
A natural next step: your own router VM can point straight at this DNS server.
Power Cost Calculator
Figure out what an always-on container like this actually costs to run.
Proxmox Updates
What's new in Proxmox VE, kept current with a live feed.
Frequently Asked Questions
Pi-hole or AdGuard Home: which should I run?
Either blocks ads and trackers network-wide just fine, and both install the same way below. Pi-hole has the bigger community and a decade of forum answers and tutorials behind it, and its post-v6 interface has a dedicated section for local DNS records that a lot of people find more logical to work in. AdGuard Home's real edge is built-in support for encrypted DNS (DoH, DoT, DoQ) with no extra service required, plus native per-client controls that make parental-style filtering by device easier to set up. If you want the larger support community, go Pi-hole. If encrypted upstream DNS or per-device rules matter to you, go AdGuard Home. Neither is a wrong choice.
Is there a one-line community script for this, like the other guides on this site?
Yes, for both. Proxmox VE Helper Scripts has a dedicated LXC installer for each: run its Pi-hole script or its AdGuard Home script and it builds the container, installs the app, and leaves you with a URL and the next command to run, all in one step. This is one of the few app-install guides on this site where the community script covers the whole job, not just the container shell.
Can I run both Pi-hole and AdGuard Home at the same time?
You can, in separate containers, but there's rarely a good reason to on a single home network. Both do the same job (DNS-based blocking), and running two means picking one as your actual DNS server and leaving the other idle, or splitting devices between them for no real benefit. The one case where it's worth it is redundancy: a second instance as a backup resolver so a reboot of the primary container doesn't take DNS down with it. If you want that, keep the second instance simple and don't try to keep its blocklists and settings in perfect sync unless you're prepared to manage that yourself.
How is this different from running Pi-hole in Docker, like the icon list on the Docker guide mentions?
Same software, different container technology. The Docker guide on this site covers Pi-hole as one of ten example containers running inside a Debian LXC's Docker Engine, useful if you already have a Docker host and want to add it there. This guide is the dedicated path: Pi-hole or AdGuard Home as its own lightweight LXC container, no Docker layer in between. For a DNS server specifically, most people run it this way rather than inside Docker, since it's one less layer between the app and the network, and the community script handles the whole setup in one command.
If the container goes down, does my whole network lose internet?
It loses DNS, which looks like losing the internet to most people and devices, since nothing can resolve a domain name to an IP address anymore. This is the real tradeoff of making any single box your network's only DNS server. Always set a secondary DNS server in your router's settings, even a public one like 1.1.1.1 or 9.9.9.9, as a fallback. You'll lose ad-blocking during an outage, not the entire internet, and that's a much better failure mode.
Do I need a privileged LXC container for this?
No, and the community scripts for both projects default to unprivileged, which is the right call for something that's just listening on a couple of network ports. If you ever build the container by hand instead of using the script, one gotcha to know about: Pi-hole's FTL resolver can hit a systemd permissions issue in an unprivileged container and needs container nesting enabled to run cleanly. The official script already accounts for this, which is one more reason to use it instead of a from-scratch install.