AdGuard Home: a DNS sinkhole with a beta channel to watch

The scripted install pipes a shell from the master branch into sh

The primary install is one line, offered in three spellings because the target system matters:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

with a `wget --no-verbose -O -` variant and a `fetch -o -` variant pointing at the same URL. Note where that URL points. It is the `master` branch, which is the default branch, and the build Makefile sets `CHANNEL = development` as its default, so the script you fetch is the one on the development line. The other three routes are quieter. There is a manual path documented on the project wiki, an official image on Docker Hub under `adguard/adguardhome`, and a Snap Store package described as the easy option on Linux. A reader choosing between them is really choosing between letting a remote script decide where files land, taking a container, or pinning a package.

A -b tag is a numbered build, not a release

The script takes four options: `-c <channel>` to use a specified channel, `-r` to reinstall, `-u` to uninstall, and `-v` for verbose output. The last two are mutually exclusive, which the project states plainly. The first is the one to think about, because the release list shows what a channel means in practice. Alongside the stable v0.107.79 from 2026-08-18 there are v0.108.0-b.91 from 2026-09-28 and v0.108.0-b.90 from 2026-07-30. That suffix is a build counter inside a 0.108.0 line, and the numbers climb on their own schedule. So a beta channel is a moving target that produces a new artefact whenever the project decides to, and the useful question is not whether the beta is newer but whether you want your resolver's configuration to be read by code that has not shipped as a release.

main.go and main_next.go sit in the same tree as client and client_v2

Look at the top level and the migration is visible. There is `main.go` and `main_next.go`, and there is both a `client/` directory and a `client_v2/` directory. The Makefile picks one, setting `CLIENT_DIR = client_v2` and passing it to npm as a prefix, and it carries a `NEXTAPI = 0` switch alongside. The frontend is also a build-time choice rather than a given: `FRONTEND_PREBUILT` defaults to 0, which fetches frontend and backend dependencies and builds the frontend, while setting it to 1 fetches only the backend dependencies and leaves the frontend alone. The practical consequence is that two interfaces exist in the repository at once and the build tells you which one it used. It also explains the repository's declared primary language being TypeScript rather than Go, since the served interface is the larger half by file count.

Blocking is name re-routing, so the resolver is the whole reach

The mechanism is DNS sinkholing, stated in the project's own comparison section, and the project's own follow-up note is that this is a starting point rather than a destination. A server re-routes tracking domains to a black hole so devices never reach them, which is why no client-side software is needed and why one server covers every device on the network that asks it. The dependency list shows what that costs in libraries. `miekg/dns` at 1.1.72 and `quic-go` at 0.61.0 are the DNS and encrypted-DNS side, `AdguardTeam/dnsproxy` at 0.84.2 is the proxy layer, and `AdguardTeam/urlfilter` at 0.23.4 is the filtering engine. An `insomniacslk/dhcp` dependency is present as well, alongside a comment saying the ping and packet libraries are to be removed together with the dhcpd package. The boundary to hold: anything that resolves names another way is outside this reach.

A YAML dependency is pinned to a release candidate, and the file says so

The module file is unusually candid about its own debts. `go.yaml.in/yaml/v4` is required at `v4.0.0-rc.6` with a comment reading TODO, update to a stable tag, which means the configuration path of this project runs on a pre-release parser. Two more dependencies carry comments saying they are deprecated, one for `github.com/go-ping/ping` and one for `github.com/mdlayher/raw`, and both are slated for removal along with the dhcpd package. Storage is `go.etcd.io/bbolt` at 1.5.0, and logging goes through lumberjack. The consequence for a reader is not alarm, it is legibility. When a build breaks on a Go upgrade, this file has already told you which lines are the soft ones, and the deprecation notes double as a map of what is scheduled to disappear. It is more than most projects publish.

The Pi-Hole comparison is an argument about packaging, made by the vendor

The project compares itself to Pi-Hole directly, and the shape of the argument matters more than the conclusion. Both are described as blocking ads and trackers with DNS sinkholing, and both as allowing customisation of what is blocked. The claimed difference is that AdGuard Home's features work out of the box with no additional software to install and configure, and the README adds a note that some of the same features can be had on Pi-Hole by installing extra software or by SSH-ing in and reconfiguring a utility, while stating in the project's own words that this should not be counted as a Pi-Hole feature. Read that as a packaging argument, one install against several, and as vendor framing rather than an independent test. The contents also list a Known limitations section, which is where the other side of the ledger belongs, and a section on how the project differs from the public AdGuard DNS servers, where running your own buys you query logs, custom rules and control over the block list.

Integration goes through the openapi directory, and signing uses your own key

The supported way to automate against AdGuard Home is the REST API, whose specification lives in the `openapi/` directory in the repository. There is a Python client published on PyPI under the name `adguardhome`, and the project points at a Home Assistant integration built on it. So if you are not reconfiguring devices by hand, that client plus the OpenAPI description is the surface to code against, and the specification is versioned with the source rather than on a separate site. One build detail worth knowing if you package it yourself: the Makefile sets `SIGN = 1` and carries `GPG_KEY = [email protected]` with `GPG_KEY_PASSPHRASE = not-a-real-password`. That passphrase is a placeholder so the file parses on a developer machine. If you build your own artefact you supply your own key, and nothing in this repository is a credential you can reuse.

Editorial conclusion

AdGuard Home fits a household or small network where the router can point every client at one resolver and someone will actually read the query log. It does not fit a network where devices bypass DNS by other means, because the mechanism is re-routing names, not filtering traffic. Before installing, decide whether you want the stable line or the beta line, since the script takes a channel argument and the current beta tag is a numbered build rather than a release. After installing, the `openapi/` directory and the `adguardhome` Python client are the supported way to integrate anything with it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes