AdGuard Home: The Self-Hosted DNS Filter That Blocks Ads on Every Device You Own — Even the Ones You Can't Install Anything On

A browser extension protects one browser. A DNS filter protects the whole network — including the smart TV that has no browser, no settings menu, and no intention of ever getting one.

There is a category of device in your house that no amount of software can protect. The smart TV that phones home every ninety seconds. The robot vacuum. The smart speaker. The games console. The set-top box. The cheap Android tablet the kids use. None of them can run uBlock Origin. Most of them cannot run anything at all. And there is a second category that is arguably worse: the phone. You can install a content blocker in the browser, but the tracking SDKs inside your apps do not go through the browser. They resolve domains directly. Instagram's tracker, the advertising ID collector in a free flashlight app, the analytics payload in a shopping app — all of it bypasses your extension entirely, because it never touches a web page. AdGuard Home is the answer to both categories, and it works by moving the filtering point down one layer of the stack. Instead of inspecting pages after they load, it intercepts the moment a device asks "what is the IP address for tracker.example.com?" and simply refuses to answer. Roughly 36,000 GitHub stars, GPL-3.0, written in Go, distributed as a single static binary with the web interface compiled into it. It is one of the highest-leverage pieces of self-hosted infrastructure you can deploy, and it is also one of the easiest to get quietly wrong. This is a deep-dive on how it works, what it genuinely blocks, the three deployment topologies and which one you actually want, the real cost, and — the part most AdGuard Home write-ups skip — the specific setting that sends your browsing data off your network, plus the failure mode where you lose DNS for the entire house at once.

1. What AdGuard Home Is

AdGuard Home is a network-wide DNS sinkhole. You point your devices, or your router, at it for DNS resolution. It answers queries for legitimate domains and refuses queries for domains on its block lists. Because every network connection starts with a DNS lookup, blocking at that layer stops the connection before it is ever established. It is built by AdGuard Software Ltd., the same company behind the commercial AdGuard ad blocker and the public AdGuard DNS service. That relationship matters in two directions. On the positive side, the filtering engine is shared with a mature commercial product, which means the rule-matching code has been hammered on at a scale most hobbyist projects never see. On the negative side, the company operates a commercial DNS service, and there are features in this self-hosted product that talk to it. We will get to those in section 17, because they are the single most important privacy detail in the whole system. What makes AdGuard Home different from its closest competitors is what ships in the box:

• Encrypted DNS as both client and server. It can forward your queries upstream over DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC, or DNSCrypt, and it can serve those same protocols to your own devices.
• A built-in DHCP server. If your router will not let you change the DNS server it hands out, AdGuard Home can take over address assignment entirely.
• Parental controls and Safe Search, enforced at the network level.
• A REST API, so you can script it.
• A web dashboard with per-client statistics and a query log.

All of that lives in one binary with no external database, no message queue, and no cache server. That design choice is why it runs happily on a Raspberry Pi that is already doing three other jobs.

2. The Problem: The Devices You Cannot Install Anything On

To understand why DNS filtering is worth the trouble, it helps to be concrete about what browser-based blocking misses. A content blocker operates on the rendered page. It has a DOM, a list of loaded resources, and a set of filter rules describing which URLs and elements to remove. This is powerful and precise — it can hide a specific div on a specific page. But it is also fundamentally limited to the application it runs inside. Here is what it cannot touch: Smart TVs and streaming devices. A Samsung TV, an Apple TV, a Roku, a Fire Stick. These run tracking and advertising SDKs at the system level. Some of them do not allow you to install a DNS setting at all, which is a special kind of hostile. IoT devices. Your doorbell, thermostat, camera, and vacuum. Many of them report usage telemetry continuously. The vendor is the customer; you are the product. Mobile apps. App-embedded SDKs resolve their own domains. The number of distinct tracking domains a typical free Android app contacts is genuinely uncomfortable to look at, and you will see it for yourself in the query log within about an hour of installing AdGuard Home. Games consoles. System-level ad panels and telemetry. Guest devices. When someone visits and joins your Wi-Fi, you cannot install an extension on their laptop. You do not have to. Every one of those devices performs DNS lookups. DNS is the one layer of the network stack that all of them, without exception, participate in. That is the entire argument for a network-level filter: it is the lowest common denominator, and the denominator happens to be universal.

3. How DNS Sinkholing Actually Works

The mechanism is almost embarrassingly simple, which is part of why it is reliable. 1. A device on your network wants to load ads.doubleclick.net. Before it can open a connection, it needs an IP address, so it sends a DNS query to whatever resolver it has been configured to use — which is now AdGuard Home. 2. AdGuard Home checks its local cache. A cache hit is answered immediately. 3. On a miss, it walks the filtering pipeline: custom DNS rewrites, then block lists, then (if enabled) Safe Browsing and Parental Controls, then blocked services, then Safe Search enforcement. 4. If the domain matches a blocking rule, AdGuard Home returns a non-answer. By default that is 0.0.0.0, but you can change the response mode to NXDOMAIN, REFUSED, or a specific IP of your choosing. 5. If nothing matches, the query is forwarded to your upstream resolver — plain DNS, DoH, DoT, DoQ, or DNSCrypt depending on how you configured it — and the real answer is returned and cached. The critical property is that steps 1 through 5 happen before any connection is established. The advertising request is not loaded and then hidden. It never gets an address to connect to. No TCP handshake, no TLS handshake, no cookies, no tracking pixel fired, no bandwidth consumed beyond the query itself. The corollary is the first hard limitation, and it is worth internalising now: the granularity is the domain. You cannot block /page-specific-ad or hide an element inside a page. You can block example.com or you can allow it. There is no in-between, and that shapes everything that follows.

4. The Single Binary

The deployment story is unusually clean, and the reason is visible in about six lines of main.go: ``go //go:embed build var clientBuildFS embed.FS func main() { home.Main(clientBuildFS) } ` The React-based admin interface is built ahead of time and its assets are embedded directly into the Go binary using go:embed. There is no Node process running at runtime. There is no separate static file server. There is no reverse proxy needed internally. You ship one file, and it serves its own UI. Persistence uses bbolt, an embedded key-value store — the same engine that backs etcd. Query history and statistics live on local disk in a B+tree rather than in an external database. This is the right trade for something meant to run unattended on a router, and it has one practical consequence: your backup is a file copy. The filtering engine itself is urlfilter, shared with AdGuard's browser extensions and public DNS service. The DNS machinery is dnsproxy on top of miekg/dns. QUIC support comes from quic-go. DHCP comes from insomniacslk/dhcp. Cross-platform service installation — systemd, launchd, Windows services — comes from kardianos/service. The codebase is organised by concern rather than by layer, with packages prefixed agh to avoid collisions: aghnet for network utilities, aghos for OS abstraction, aghtls for TLS handling, aghuser for authentication, and so on across some twenty-nine internal packages. That naming convention is a small thing that makes a large tree navigable. One honest note from reading the source: several dependencies carry inline TODOs flagging them as deprecated, including go-ping/ping and mdlayher/raw, with maintainers acknowledging they need replacing "along with the dhcpd package." That is a quiet signal that the DHCP subsystem is considered legacy-ish internally. It works. It is not where development energy is going.

5. Filtering: Rules, Lists, and Syntax

On first launch, AdGuard Home enables the AdGuard DNS filter by default and offers the AdAway Default Blocklist as an option. The UI exposes dozens of additional lists — general, security, regional, and specialised — sourced from AdGuard's HostlistsRegistry and grouped by category. The rule syntax is AdGuard's own, and it is more expressive than a hosts file: ` ||tracker.example.com^ @@||allow.example.com^ 192.168.1.10 home.local example.com$dnsrewrite=127.0.0.1 ` The first blocks the domain and all its subdomains. The second is an exception — an un-block, which you will need more often than you expect. The third is a local A record, which is how you give your home-lab services real hostnames without running a separate DNS server. The fourth rewrites a response to a different address. DNS rewrites are quietly one of the most useful features in the whole product. Being able to say "everything on my network resolves nas.home to 192.168.1.20" without standing up BIND or dnsmasq configuration is a genuine quality-of-life win, and it is the feature that makes people keep AdGuard Home even after they stop caring about ad blocking. The response mode deserves a specific recommendation. The default of returning 0.0.0.0 causes some clients to retry or hang, because 0.0.0.0 is a syntactically valid address they will attempt to connect to. NXDOMAIN is generally the better choice — it tells the client the domain does not exist, which most software handles gracefully and immediately. If you have ever wondered why a page seems to stall for a few seconds on a blocked resource, this is usually why.

6. Encrypted DNS, In Both Directions

AdGuard Home handles encrypted DNS in two distinct roles, and confusing them is a common source of misconfiguration. Outbound (upstream). Your queries leave AdGuard Home for a resolver on the internet. You can encrypt that hop: `yaml upstream_dns: - tls://unfiltered.adguard-dns.com - https://dns.cloudflare.com/dns-query - quic://unfiltered.adguard-dns.com ` Three upstream strategies are available:

• load_balance — round-robin across upstreams.
• parallel — query several upstreams at once and take the fastest response.
• fastest_addr — actually measure latency and return the lowest-latency address.

You will also want to configure bootstrap_dns (used to resolve the hostname of your DoH/DoT upstream, which is a chicken-and-egg problem otherwise) and fallback_dns (used when every upstream fails). Skipping bootstrap_dns is the cause of a specific and confusing failure: everything works, then you reboot, and DNS is dead because AdGuard Home cannot resolve the name of the server it is supposed to send encrypted queries to. Inbound (served). AdGuard Home can be an encrypted DNS server for your devices. Supply a TLS certificate and it can listen for DoH, DoT, and DoQ on their respective ports, with DNSCrypt and DDR also supported. DoT and DoQ can identify clients by SNI, which lets you apply different policies to different devices even when they are outside your network. That last capability is what makes AdGuard Home viable as a personal resolver for a phone on cellular data — but it also means you are exposing a resolver to the internet, which is how open resolvers used in DNS amplification attacks get created. If you do this, restrict who can reach it.

7. The Built-In DHCP Server

Most consumer routers let you change the DNS server handed out via DHCP. Some do not. Some do, but silently override it. A few ISP-provided gateways simply refuse. For those cases, AdGuard Home ships a DHCP server. You disable DHCP on the router, enable it in AdGuard Home, and now every device that joins the network receives AdGuard Home as its DNS server automatically — no per-device configuration, no manual work when a guest arrives. It supports static leases and IPv6 router advertisement, so the basics are covered. Two caveats: If you run it in Docker, you need host networking. DHCP uses raw sockets and broadcast traffic that does not survive bridge networking. The same is true if you want AdGuard Home to see real client IP addresses rather than the Docker gateway address — without host networking, every query looks like it came from the same host, and per-client policies become useless. You now have two DHCP servers to reason about. Leaving both the router's and AdGuard Home's enabled produces intermittent, baffling behaviour where some devices get the right DNS and some do not, depending on which server answered first. Turn one off. Check twice.

8. Deployment: Docker

The official image is adguard/adguardhome. The canonical run command mounts two directories separately: `bash docker run --name adguardhome \ --restart unless-stopped \ -v /my/own/workdir:/opt/adguardhome/work \ -v /my/own/confdir:/opt/adguardhome/conf \ -p 53:53/tcp -p 53:53/udp \ -p 80:80/tcp -p 443:443/tcp \ -p 3000:3000/tcp \ -p 853:853/tcp -p 853:853/udp \ -d adguard/adguardhome ` Separating the work and conf directories matters for backup hygiene: conf holds AdGuardHome.yaml and is small and worth versioning; work holds the query log database and is large and churny. If you are running it on a Linux host alongside other services, or you want real client IPs, or you need DHCP, use: `bash --network host ` The first launch binds to port 3000 for the setup wizard. You will complete the wizard there, after which the admin interface moves to port 80 (or 443 if you configure TLS). Leaving 3000 exposed after setup is unnecessary and, given the wizard can re-run, a bad idea.

9. Deployment: Native and Raspberry Pi

For a Raspberry Pi — which is what a very large fraction of these installations are — the binary route is simpler than Docker. `bash curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v cd AdGuardHome sudo ./AdGuardHome -s install ` That registers it as a system service. Manage it with -s start, -s stop, and -s restart. ARM builds are published for the Pi, including armv6 for the older boards. Building from source needs Go 1.25+, Node.js 24.10+, and npm 10.8+, and one quirk worth knowing: the Makefile does not support parallel builds. Use make -j 1 or you will get confusing failures that look like dependency problems and are not. For hardware sizing, this is a genuinely lightweight workload. A Pi Zero W will handle a household. A Pi 4 is comfortable with room to spare. CPU is almost never the bottleneck; rule count and upstream latency are.

10. The Port Map, and the systemd-resolved Trap

| Port | Protocol | Purpose | |---|---|---| | 53 | TCP/UDP | Plain DNS | | 80 | TCP | Admin web interface (after setup) | | 443 | TCP/UDP | Admin UI over HTTPS, and DoH | | 3000 | TCP | Initial setup wizard | | 853 | TCP/UDP | DoT and DoQ | | 5443 | TCP/UDP | DNSCrypt | The single most common installation failure is port 53 already being in use. On modern Ubuntu and Debian, systemd-resolved binds a stub resolver to 127.0.0.53:53, and Docker will fail to bind, or AdGuard Home will start and quietly not serve anything. Diagnose it: `bash sudo lsof -i :53 sudo ss -tulpn | grep :53 ` Fix it by disabling the stub listener: `bash sudo sed -i 's/#DNSStubListener=yes/DNSStubListener=no/' /etc/systemd/resolved.conf sudo systemctl restart systemd-resolved ` This bites people who are otherwise entirely competent at Linux administration, and it is worth checking first rather than third.

11. Three Ways to Point Your Network at It

Option A: Router DHCP. Change the DNS server your router advertises to AdGuard Home's IP. Every device picks it up on the next lease renewal. This is the cleanest option and the one to use if your router supports it. Option B: Built-in DHCP. Disable DHCP on the router, enable it in AdGuard Home. Use this when the router refuses to let you change DNS. Option C: Per-device. Manually set the DNS server on individual devices. This is the "bypass gateway" or side-car approach. It is the least invasive — nothing changes for anyone else on the network, and if AdGuard Home dies, only the devices you configured are affected. It is also the most work, and it does nothing for devices you cannot configure. For most home deployments, A is right. For a shared household where one person is going to be annoyed when something breaks, C is the politically safer choice.

12. The Query Log Is the Actual Product

The ad blocking is the headline feature. The query log is the one that changes how you think about your network. AdGuard Home records every DNS query, with the client that made it, the response, and the reason — allowed, blocked by list, blocked by category, and so on. Retention defaults to 90 days for the query log and 1 day for aggregate statistics. Leave it running for a week, then sort by client and look at your smart TV. Look at your phone. Look at the doorbell. The volume of outbound telemetry from devices that have no business making outbound connections is, on most home networks, genuinely startling. Two practical notes: Retention is a privacy setting, not just a disk setting. Ninety days of every domain every device in your house resolved is a detailed profile of the household. That log is on your hardware, which is the point — but it is also the most sensitive file on that hardware. If you do not need it, turn it down. The log is the best block list tuning tool you have. When something breaks, the query log tells you exactly which domain was blocked and why. Ninety percent of "AdGuard Home broke my app" is resolved by finding the blocked domain in the log and adding an @@ exception.

13. Per-Client Policies

Clients can be identified by IP, MAC address, or by a persistent client ID, and grouped into "client groups." Filtering rules, blocked services, and Safe Search can then be applied per group. This is how you build a sane household setup: strict filtering and bedtime restrictions on the kids' devices, permissive filtering on your own workstation, and no filtering at all on the device that keeps breaking. The catch is that per-client identification depends on seeing real client IPs, which brings us back to host networking on Docker. With bridge networking, every device looks identical and this entire feature is inert.

14. Blocked Services and Safe Search

Blocked Services is a curated layer above raw block lists. It groups roughly 290-plus services into about twelve categories — social, video, gaming, shopping, AI, gambling, and so on — and lets you block them by ticking a box rather than hunting for domains. Blocking "all social media between 9pm and 7am" for a specific client group is a five-minute job. Safe Search forces search engines into their safe mode by rewriting responses: Google, Bing, YouTube, DuckDuckGo, Ecosia, Pixabay, and Yandex are supported. The enforcement happens at the DNS layer, so it applies to devices where you could not otherwise enforce anything. Both features work as advertised. Both are also, strictly speaking, content policy features rather than privacy features, and it is worth being honest with yourself about which one you are actually using them for.

15. What DNS Blocking Cannot Do

This is where marketing copy and reality diverge, and AdGuard's own documentation is refreshingly direct about it. YouTube ads. The ads and the video are served from the same domains. There is no DNS-level distinction to make. This is not a tuning problem; it is architecturally unsolvable at this layer. Twitch ads. Same problem, same reason. Sponsored posts inside social apps. A promoted tweet and an organic tweet come from the same API endpoints. DNS cannot see the difference. Same-domain ads. If an ad is served from the same domain as the content, blocking the domain blocks the content. Anything requiring content inspection. AdGuard Home does not see HTTPS payloads. It cannot inspect page contents, remove page elements, or filter by URL path. It is not a TLS-intercepting proxy, and treating it like one will only produce confusion. The correct mental model: DNS filtering and browser extensions are complementary, not competing. The extension does precision work inside the browser. AdGuard Home does broad coverage everywhere else. People who run both report the best results; people who run only one and expect it to do the other's job end up disappointed.

16. The Encrypted DNS Bypass

Here is a leak that surprises people. If a device is configured to use its own encrypted DNS — Android's Private DNS, a browser's built-in DoH, a VPN — then it is not asking your AdGuard Home anything. It is tunnelling encrypted DNS straight past your filter to a resolver of its own choosing. Your blocking does not apply. Your query log does not see it. Android's Private DNS setting is the most common offender, because several phones enable it by default when they detect a DoT-capable network. Firefox and Chrome both ship DNS-over-HTTPS that can be enabled independently. You can mitigate it by blocking known DoH provider domains at the DNS level, which is a partial and somewhat arms-racy defence. You can also firewall outbound port 853 for devices you control. But the honest framing is this: a network DNS filter governs devices that consent to be governed. On a network you administer with devices you own, it is comprehensive. On a network with technically inclined guests, it is advisory.

17. Where Your Data Goes — Including the One Place It Leaves

The core promise is that your query stream stays on hardware you control. For the default configuration, that promise holds. No query log is shipped anywhere. No usage statistics are collected by default. Filtering decisions are made locally against locally-cached lists. There is one exception, and it is buried in two optional features. Safe Browsing and Parental Controls both work by sending a hash prefix of the queried domain to family.adguard-dns.com to check it against a remote database. A local 1 MiB cache reduces repeat lookups, but the first lookup for a domain goes out. Let that land. These two features — the ones most likely to be turned on by a parent, and the ones that sound most like "local safety enforcement" — are the only parts of AdGuard Home that transmit information about your browsing off your machine. Is it bad? Not really. It is a hash prefix, not a full URL, and it goes to a company with a commercial reputation to protect. It is disclosed in the documentation. It is not covert. Is it worth knowing? Absolutely. If your reason for self-hosting is "nothing about my network traffic leaves my network," then you must leave Safe Browsing and Parental Controls disabled and rely on local block lists instead. That is a real capability trade — the remote databases are larger and more current than anything you will maintain by hand — but it is your call to make deliberately rather than by default. Compare this to the alternative it usually replaces. A managed filtering DNS service answers every single query your devices make, and therefore has a complete record of everywhere your network went. That record lives on vendor infrastructure, in a jurisdiction you did not choose, under a retention policy you did not set. The difference between that and AdGuard Home with two optional features disabled is not incremental. It is categorical.

18. What It Actually Costs

| Component | Managed filtering DNS | AdGuard Home self-hosted | |---|---|---| | License | Subscription, scales with query volume | $0 — every feature, GPL-3.0 | | Hardware | None | ~$35–60 Pi one-time, or $0 on hardware you own | | Power | $0 | ~$3–5/year for a Pi, running continuously | | Data custody | Vendor holds your query log | You hold your query log | | Maintenance | None | Block list and version updates, maybe 20 min/month | The recurring cost is close to nil. A Raspberry Pi draws somewhere in the range of 3–7 watts depending on model and load; at typical electricity rates that is a few dollars a year. If you already run a home server, NAS, or a Pi doing something else, the marginal cost is zero. The real cost is maintenance attention: updates, the occasional filter-list breakage, and the one afternoon you spend debugging after an OS upgrade eats systemd-resolved again. Budget twenty minutes a month and you will be fine. Against a paid filtering service, the financial argument is almost trivially won. The argument that actually decides it is the third row of that table.

19. AdGuard Home vs Pi-hole vs Technitium

Pi-hole is the better-known name, with roughly 60,000 stars and a longer history in the homelab community. It does the same core job well. The practical differences: Pi-hole's ecosystem and documentation are broader, its blocking is regex-and-list based, and it expects you to bolt on a separate DNS server if you want recursive resolution. AdGuard Home ships encrypted DNS and DHCP in the box rather than as adjacent projects. Licensing differs too — Pi-hole is EUPL-1.2, AdGuard Home is GPL-3.0. Technitium DNS Server, at around 9,500 stars, is the more complete DNS platform: authoritative zone hosting, DNSSEC signing, clustering, a full-featured API. If you want DNS as managed infrastructure, Technitium is the fuller answer. If you want a filtering appliance that you set up once and forget, AdGuard Home is simpler. Blocky (Apache-2.0, ~7,000 stars) is the lightweight, config-file-driven alternative for people who find both of the above too heavy and do not want a web UI. The honest summary: AdGuard Home's strength is the batteries-included middle. It is not the most powerful DNS server and not the most extensible filter. It is the one where a single binary gives you filtering, encrypted transport in both directions, DHCP, per-client policy, and a good dashboard, and then gets out of your way.

20. Honest Limitations

No clustering, no high availability. There is no native replication or failover. Two instances means two independent configurations you keep in sync yourself — block lists, custom rules, client definitions. There is no built-in mechanism to help you. Which makes it a single point of failure. When AdGuard Home goes down, DNS goes down, and when DNS goes down everything looks broken. Your family will not think "the DNS server is down." They will think "the internet is broken." If you have ever had a household-wide outage panic, this is how it happens. Consider whether you want a secondary resolver configured on your network as a fallback. Single admin, no SSO. One set of credentials. No role separation, no LDAP, no OIDC. Fine for a home, limiting for an organisation. Not an authoritative DNS server. No zone hosting, no DNSSEC signing. It forwards to an upstream by default, which means your upstream still sees your queries unless you encrypt that hop — or run a recursive resolver like Unbound alongside it and resolve from the root yourself. Enterprise readiness is low by design. This is an appliance for a network you own, not a platform for a network you manage professionally. The domain granularity limit from section 15, which no amount of configuration will fix. DHCP is internally regarded as legacy per the source TODOs. It works today; do not build something critical on it.

21. Performance and Sizing

DNS is a tiny amount of traffic on a fast path, and AdGuard Home is not typically the bottleneck. The default 4 MiB DNS cache is generous for a household — a large fraction of queries are repeats, and a healthy cache hit rate means most queries never touch an upstream at all. If you are serving a larger network, raising the cache size is cheap and effective. Where performance does degrade is rule count. Each additional million-domain block list adds matching work per query. On a Pi-class device, a dozen aggressive lists plus regex rules is still fine; dozens of lists start to show. Add lists until things break, then back off one — that is a legitimate tuning strategy, and the query log will tell you which lists are actually doing work. Upstream choice matters more than local tuning. parallel mode improves perceived latency by racing upstreams. fastest_addr gives better subsequent connection performance but generates additional measurement traffic and, notably, leaks a bit more query information to multiple upstreams simultaneously.

22. Troubleshooting

Port 53 in use. Covered in section 10. Check systemd-resolved first. All clients show the same IP in the query log. You are on Docker bridge networking. Switch to host networking. DNS works but nothing is blocked. The clients are not actually using AdGuard Home. Verify with nslookup against the AdGuard Home IP explicitly, then check what DNS your router is actually handing out — some routers advertise themselves regardless of what you configured. Encrypted upstream fails after a reboot. Missing or unreachable bootstrap_dns. A specific site or app is broken. Open the query log, filter to blocked, find the domain, add an @@||domain^ exception. This resolves the overwhelming majority of cases. The admin UI is unreachable. Post-setup it moves from port 3000 to port 80 (or 443). You are probably knocking on the wrong door. Blocked pages hang for a few seconds. Switch the response mode from 0.0.0.0 to NXDOMAIN. Two DHCP servers fighting. You left the router's enabled. Turn one off.

23. Backup, Redundancy, and Failure Modes

Your backup is genuinely simple, which is one of the underrated virtues of the no-external-database design:

• /opt/adguardhome/conf/AdGuardHome.yaml — the entire configuration. Small, text, version it in git.
• /opt/adguardhome/work/` — the query log database. Back it up if you care about history; skip it if you do not.

Restoring is copying those back and restarting. There is no schema migration story, no database dump and restore, no consistency to reason about. For redundancy, the honest recommendation for a home network is not a second AdGuard Home instance — it is configuring a secondary DNS server on your network so that a failure degrades to unfiltered internet rather than no internet. A router that hands out AdGuard Home as primary and your ISP or a public resolver as secondary gives you a soft landing. Devices will use the secondary when the primary is unreachable, which means an outage becomes "ads came back" instead of "the internet is broken." That is a meaningful trade — during an outage, some queries bypass filtering — and for most households it is the right one.

24. Who Should Run It, and Who Shouldn't

Run it if you have devices you cannot install software on, you want household-wide filtering with no per-device work, you want visibility into what your network is actually talking to, or you want a local DNS server with friendly hostnames for your home lab. Also run it if you are currently paying for a managed filtering DNS service and the idea of that vendor holding a complete log of your household's browsing bothers you. That is the highest-value migration in this entire category. Think twice if you need authoritative DNS with DNSSEC signing (use Technitium), you need clustering and SSO (this is not an enterprise product), you expect it to block YouTube ads (it will not), or you are not prepared for it to become critical infrastructure. That last one is real: once everything on your network depends on it, an unplanned outage is a household event, and you should decide in advance whether you are OK with that.

25. The Verdict

AdGuard Home is one of the best effort-to-value ratios in self-hosted software. One binary, one config file, no database, about twenty minutes to deploy, and it immediately begins covering devices that no other tool could reach. Thirty-six thousand stars and GPL-3.0 licensing mean it is not going anywhere. Its limits are honest and structural rather than artificial. It blocks at domain granularity, so it will never catch same-domain advertising. It does not cluster, so it is a single point of failure. It is not an authoritative DNS server. And if you turn on Safe Browsing or Parental Controls, domain hash prefixes leave your network — a disclosure that deserves to be more prominent than it is, and one you should decide about deliberately. The thing it replaces is worth naming precisely. A managed filtering DNS service is not just a subscription. It is a complete, permanent, third-party record of everywhere your network went, held by a company in a jurisdiction you did not choose. AdGuard Home costs a few dollars a year in electricity and puts that record on a device in your hallway instead. That is not a marginal improvement. It is the difference between renting privacy and owning it.

Related

• Pi-hole Alternative: Uptime Kuma — The Self-Hosted Status Page and Monitor That Kills Your SaaS Subscription — monitor your AdGuard Home instance so DNS outages are not a surprise.
• Traefik: The Reverse Proxy That Configures Itself — put TLS in front of the admin interface and your DoH endpoint.
• headscale: The Self-Hosted Control Server That Replaces Tailscale — the other half of a private home network, for when you are away from it.
• SearXNG: The Open-Source Metasearch Engine That Returns Results Without Building a Profile of You — privacy above the DNS layer, once DNS filtering is handled.
• ntfy: The Self-Hosted Push Notification Service That Replaces Firebase for Your Own Scripts — get alerted when your DNS resolver stops resolving.