AdGuardHome Documentation

Network-wide ads & trackers blocking DNS server

36,086 stars TypeScript TypeScript 1 file · ~7,925 tokens #adblock#adguard#dns#dns-over-https#dns-over-quic#dns-over-tls#dnscrypt#golang
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy AdGuardHome on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run) 
docker run -d --name adguardhome --restart always adguard/adguardhome
Configured Services & Ports
⚙️ adguardhome
image: adguard/adguardhome
docker-compose.yml
yaml (docker-compose.yml) 
services:
  adguardhome:
    image: adguard/adguardhome
    restart: unless-stopped

File: README.md

 

Privacy protection center for you and your devices

AdGuard Home is a network-wide software for blocking ads and tracking. After you set it up, it'll cover ALL your home devices, and you don't need any client-side software for that.

It operates as a DNS server that re-routes tracking domains to a “black hole”, thus preventing your devices from connecting to those servers. It's based on software we use for our public AdGuard DNS servers, and both share a lot of code.

[Getting Started](#getting-started)

[Automated install (Linux/Unix/MacOS/FreeBSD/OpenBSD)](#automated-install-linux-and-mac)

To install with curl run the following command:

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

To install with wget run the following command:

sh
wget --no-verbose -O - https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

To install with fetch run the following command:

sh
fetch -o - https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

The script also accepts some options:

  • -c <channel> to use specified channel;
  • -r to reinstall AdGuard Home;
  • -u to uninstall AdGuard Home;
  • -v for verbose output.

Note that options -r and -u are mutually exclusive.

[Alternative methods](#alternative-methods)

[Manual installation](#manual-installation)

Please read the Getting Started article on our Wiki to learn how to install AdGuard Home manually, and how to configure your devices to use it.

[Docker](#docker)

You can use our official Docker image on Docker Hub.

[Snap Store](#snap-store)

If you're running Linux, there's a secure and easy way to install AdGuard Home: get it from the Snap Store.

[Guides](#guides)

See our Wiki.

[API](#api)

If you want to integrate with AdGuard Home, you can use our REST API. Alternatively, you can use this python client, which can be used to build the AdGuard Home Assistant integration.

[Comparing AdGuard Home to other solutions](#comparison)

[How is this different from public AdGuard DNS servers?](#comparison-adguard-dns)

Running your own AdGuard Home server allows you to do much more than using a public DNS server. It's a completely different level. See for yourself:

  • Choose what exactly the server blocks and permits.

  • Monitor your network activity.

  • Add your own custom filtering rules.

  • Most importantly, it's your own server, and you are the only one who's in control.

[How does AdGuard Home compare to Pi-Hole](#comparison-pi-hole)

At this point, AdGuard Home has a lot in common with Pi-Hole. Both block ads and trackers using the so-called “DNS sinkholing” method and both allow customizing what's blocked.

[!NOTE]
We're not going to stop here. DNS sinkholing is not a bad starting point, but this is just the beginning.

AdGuard Home provides a lot of features out-of-the-box with no need to install and configure additional software. We want it to be simple to the point when even casual users can set it up with minimal effort.

[!NOTE]
Some of the listed features can be added to Pi-Hole by installing additional software or by manually using SSH terminal and reconfiguring one of the utilities Pi-Hole consists of. However, in our opinion, this cannot be legitimately counted as a Pi-Hole's feature.

Feature AdGuard Home Pi-Hole
Blocking ads and trackers ✅ ✅
Customizing blocklists ✅ ✅
Built-in DHCP server ✅ ✅
HTTPS for the Admin interface ✅ Kind of, but you'll need to manually configure lighttpd
Encrypted DNS upstream servers (DNS-over-HTTPS, DNS-over-TLS, DNSCrypt) ✅ ❌ (requires additional software)
Cross-platform ✅ ❌ (not natively, only via Docker)
Running as a DNS-over-HTTPS or DNS-over-TLS server ✅ ❌ (requires additional software)
Blocking phishing and malware domains ✅ ❌ (requires non-default blocklists)
Parental control (blocking adult domains) ✅ ❌ (requires non-default blocklists)
Force Safe search on search engines ✅ ❌
Per-client (device) configuration ✅ ✅
Access settings (choose who can use AGH DNS) ✅ ❌
Running without root privileges ✅ ❌

[How does AdGuard Home compare to traditional ad blockers](#comparison-adblock)

It depends.

DNS sinkholing is capable of blocking a big percentage of ads, but it lacks the flexibility and the power of traditional ad blockers. You can get a good impression about the difference between these methods by reading this article, which compares AdGuard for Android (a traditional ad blocker) to hosts-level ad blockers (which are almost identical to DNS-based blockers in their capabilities). This level of protection is enough for some users.

Additionally, using a DNS-based blocker can help to block ads, tracking and analytics requests on other types of devices, such as SmartTVs, smart speakers or other kinds of IoT devices (on which you can't install traditional ad blockers).

[Known limitations](#comparison-limitations)

Here are some examples of what cannot be blocked by a DNS-level blocker:

  • YouTube, Twitch ads;

  • Facebook, Twitter, Instagram sponsored posts.

Essentially, any advertising that shares a domain with content cannot be blocked by a DNS-level blocker.

Is there a chance to handle this in the future? DNS will never be enough to do this. Our only option is to use a content blocking proxy like what we do in the standalone AdGuard applications. We're going to bring this feature support to AdGuard Home in the future. Unfortunately, even in this case, there still will be cases when this won't be enough or would require quite a complicated configuration.

[How to build from source](#how-to-build)

[Prerequisites](#prerequisites)

Run make init to prepare the development environment.

You will need this to build AdGuard Home:

  • Go v1.25 or later;
  • Node.js v24.10.0 or later;
  • npm v10.8 or later;

[Building](#building)

Open your terminal and execute these commands:

sh
git clone https://github.com/AdguardTeam/AdGuardHome
cd AdGuardHome
make

[!WARNING]
The non-standard -j flag is currently not supported, so building with make -j 4 or setting your MAKEFLAGS to include, for example, -j 4 is likely to break the build. If you do have your MAKEFLAGS set to that, and you don't want to change it, you can override it by running make -j 1.

Check the Makefile to learn about other commands.

[Building for a different platform](#building-cross)

You can build AdGuard Home for any OS/ARCH that Go supports. In order to do this, specify GOOS and GOARCH environment variables as macros when running make.

For example:

sh
env GOOS='linux' GOARCH='arm64' make

or:

sh
make GOOS='linux' GOARCH='arm64'

[Preparing releases](#preparing-releases)

You'll need snapcraft to prepare a release build. Once installed, run the following command:

sh
make build-release CHANNEL='...' VERSION='...'

See the build-release target documentation.

[Docker image](#docker-image)

Run make build-docker to build the Docker image locally (the one that we publish to DockerHub). Please note, that we're using Docker Buildx to build our official image.

You may need to prepare before using these builds:

  • (Linux-only) Install Qemu:

    sh
    docker run --rm --privileged multiarch/qemu-user-static --reset -p yes --credential yes

  • Prepare the builder:

    sh
    docker buildx create --name buildx-builder --driver docker-container --use

See the build-docker target documentation.

[Debugging the frontend](#debugging-the-frontend)

When you need to debug the frontend without recompiling the production version every time, for example to check how your labels would look on a form, you can run the frontend build a development environment.

  1. In a separate terminal, run:

    sh
    ( cd ./client/ && env NODE_ENV='development' npm run watch )

  2. Run your AdGuardHome binary with the --local-frontend flag, which instructs AdGuard Home to ignore the built-in frontend files and use those from the ./build/ directory.

  3. Now any changes you make in the ./client/ directory should be recompiled and become available on the web UI. Make sure that you disable the browser cache to make sure that you actually get the recompiled version.

[End-to-End (E2E) Frontend Tests](#e2e-frontend-tests)

AdGuard Home uses Playwright for E2E testing. Tests are located in tests/e2e.

Running Tests:

  • npm run test:e2e – run all tests (headless).
  • npm run test:e2e:interactive – run tests interactively.
  • npm run test:e2e:debug – run tests in debug mode.
  • npm run test:e2e:codegen – generate new test code.

Setup:

  1. Run npm install to install dependencies.
  2. Run npx playwright install to set up required browsers.

Warning: Playwright will download and install its own browser binaries for testing, which may differ from the browsers installed on your system.

[Contributing](#contributing)

You are welcome to fork this repository, make your changes and submit a pull request. Please make sure you follow our code guidelines though.

Please note that we don't expect people to contribute to both UI and backend parts of the program simultaneously. Ideally, the backend part is implemented first, i.e. configuration, API, and the functionality itself. The UI part can be implemented later in a different pull request by a different person.

[Test unstable versions](#test-unstable-versions)

There are two update channels that you can use:

  • beta: beta versions of AdGuard Home. More or less stable versions, usually released every two weeks or more often.

  • edge: the newest version of AdGuard Home from the development branch. New updates are pushed to this channel daily.

There are three options how you can install an unstable version:

  1. Snap Store: look for the beta and edge channels.

  2. Docker Hub: look for the beta and edge tags.

  3. Standalone builds. Use the automated installation script or look for the available builds on the Wiki.

    Script to install a beta version:

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

    Script to install an edge version:

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

[Report issues](#reporting-issues)

If you run into any problem or have a suggestion, head to this page and click on the “New issue” button. Please follow the instructions in the issue form carefully and don't forget to start by searching for duplicates.

[Help with translations](#translate)

If you want to help with AdGuard Home translations, please learn more about translating AdGuard products in our Knowledge Base. You can contribute to the AdGuardHome project on CrowdIn.

[Other](#help-other)

Another way you can contribute is by looking for issues marked as help wanted, asking if the issue is up for grabs, and sending a PR fixing the bug or implementing the feature.

[Projects that use AdGuard Home](#uses)

Please note that these projects are not affiliated with AdGuard, but are made by third-party developers and fans.

[Acknowledgments](#acknowledgments)

This software wouldn't have been possible without:

You might have seen that CoreDNS was mentioned here before, but we've stopped using it in AdGuard Home.

For the full list of all Node.js packages in use, please take a look at client/package.json file.

[Privacy](#privacy)

Our main idea is that you are the one, who should be in control of your data. So it is only natural, that AdGuard Home does not collect any usage statistics, and does not use any web services unless you configure it to do so. See also the full privacy policy with every bit that could in theory be sent by AdGuard Home is available.

File: internal/dhcpd/README.md

Testing DHCP Server

Contents:

[Test setup with Virtual Box](#vbox)

Prerequisites

To set up a test environment for DHCP server you will need:

  • Linux AG Home host machine (Virtual)
  • Virtual Box
  • Virtual machine (guest OS doesn't matter)

Configure Virtual Box

  1. Install Virtual Box and run the following command to create a Host-Only network:

    sh
    VBoxManage hostonlyif create

    You can check its status by ip a command.

    You can also set up Host-Only network using Virtual Box menu in File → Host Network Manager.

  2. Create your virtual machine and set up its network in VM Settings → Network → Host-only Adapter.

  3. Start your VM, install an OS. Configure your network interface to use DHCP and the OS should ask for a IP address from our DHCP server.

  4. To see the current IP addresses on client OS you can use ip a command on Linux or ipconfig on Windows.

  5. To force the client OS to request an IP from DHCP server again, you can use dhclient on Linux or ipconfig /release on Windows.

Configure server

  1. Edit server configuration file AdGuardHome.yaml, for example:

    yaml
    dhcp:
    enabled: true
    interface_name: vboxnet0
    local_domain_name: lan
    dhcpv4:
        gateway_ip: 192.168.56.1
        subnet_mask: 255.255.255.0
        range_start: 192.168.56.2
        range_end: 192.168.56.2
        lease_duration: 86400
        icmp_timeout_msec: 1000
        options: []
    dhcpv6:
        range_start: 2001::1
        lease_duration: 86400
        ra_slaac_only: false
        ra_allow_slaac: false

  2. Start the server:

    sh
    ./AdGuardHome -v

    There should be a message in log which shows that DHCP server is ready:

    none
    [info] dhcpv4: listening

[Quick test with DHCPTest utility](#dhcptest)

Prerequisites

Quick test

The DHCP server could be tested for DISCOVER-OFFER packets with in interactive mode.

File: openapi/README.md

AdGuard Home OpenAPI

We are using OpenAPI specification to generate AdGuard Home API specification.

How to edit the API spec

The easiest way would be to use Swagger Editor and just copy/paste the YAML file there.

Changelog

See CHANGELOG.md where we keep track of all non-compatible changes that are being made.

Authentication

If AdGuard Home’s web user is password-protected, a web client must use authentication mechanism when sending requests to server. Basic access authentication is the most simple method: a client must pass Authorization HTTP header along with all requests:

http
Authorization: Basic BASE64_DATA

Where BASE64_DATA is base64-encoded data for username:password string.

File: scripts/README.md

AdGuard Home scripts

`hooks/`: Git hooks

Usage

Run make init from the project root.

`make/`: Makefile scripts

The release channels are: development (the default), edge, beta, and release. If verbosity levels aren’t documented here, there are only two: 0, don’t print anything, and 1, be verbose.

`build-docker.sh`: Build a multi-architecture Docker image

Required environment:

  • CHANNEL: release channel, see above.

  • DIST_DIR: the directory where a release has previously been built.

  • REVISION: current Git revision.

  • VERSION: release version.

Optional environment:

  • DOCKER_IMAGE_NAME: the name of the resulting Docker container. By default it’s adguardhome-dev.

  • DOCKER_PUSH: 1 to push the image to DockerHub, 0 to not push. By default it’s 0.

  • SUDO: allow users to use sudo or doas with docker. By default none is used.

`build-release.sh`: Build a release for all platforms

Required environment:

  • CHANNEL: release channel, see above.

  • GPG_KEY and GPG_KEY_PASSPHRASE: data for gpg. Only required if SIGN is 1.

Optional environment:

  • ARCH and OS: space-separated list of architectures and operating systems for which to build a release. For example, to build only for 64-bit ARM and AMD on Linux and Darwin:

    sh
    make ARCH='amd64 arm64' OS='darwin linux' … build-release

    The default value is '', which means build everything.

  • DIST_DIR: the directory to build a release into. The default value is dist.

  • GO: set an alternative name for the Go compiler.

  • SIGN: 0 to not sign the resulting packages, 1 to sign. The default value is 1.

  • VERBOSE: 1 to be verbose, 2 to also print environment. This script calls go-build.sh with the verbosity level one level lower, so to get verbosity level 2 in go-build.sh, set this to 3 when calling build-release.sh.

  • VERSION: release version. Will be set by version.sh if it is unset or if it has the default Makefile value of v0.0.0.

We’re using Go’s forward compatibility mechanism for updating the Go version. This means that if your go version is 1.21+ but is different from the one required by AdGuard Home, the go tool will automatically download the required version.

If you want to use the version installed on your builder, run:

sh
go get go@$YOUR_VERSION
go mod tidy

and call make with GOTOOLCHAIN=local.

`go-bench.sh`: Run backend benchmarks

Optional environment:

  • GO: set an alternative name for the Go compiler.

  • TIMEOUT_FLAGS: set timeout flags for tests. The default value is --timeout=30s.

  • VERBOSE: verbosity level. 1 shows every command that is run and every Go package that is processed. 2 also shows subcommands and environment. The default value is 0, don’t be verbose.

`go-build.sh`: Build the backend

Optional environment:

  • GOAMD64: architectural level for AMD64. The default value is v1.

  • GOARM: ARM processor options for the Go compiler.

  • GOMIPS: ARM processor options for the Go compiler.

  • GO: set an alternative name for the Go compiler.

  • OUT: output binary name.

  • PARALLELISM: set the maximum number of concurrently run build commands (that is, compiler, linker, etc.).

  • SOURCE_DATE_EPOCH: the standardized environment variable for the Unix epoch time of the latest commit in the repository. If set, overrides the default obtained from Git. Useful for reproducible builds.

  • VERBOSE: verbosity level. 1 shows every command that is run and every Go package that is processed. 2 also shows subcommands and environment. The default value is 0, don’t be verbose.

  • VERSION: release version. Will be set by version.sh if it is unset or if it has the default Makefile value of v0.0.0.

Required environment:

  • CHANNEL: release channel, see above.

`go-deps.sh`: Install backend dependencies

Optional environment:

  • GO: set an alternative name for the Go compiler.

  • VERBOSE: verbosity level. 1 shows every command that is run and every Go package that is processed. 2 also shows subcommands and environment. The default value is 0, don’t be verbose.

`go-fuzz.sh`: Run backend fuzz tests

Optional environment:

  • GO: set an alternative name for the Go compiler.

  • FUZZTIME_FLAGS: set fuss flags for tests. The default value is --fuzztime=20s.

  • TIMEOUT_FLAGS: set timeout flags for tests. The default value is --timeout=30s.

  • VERBOSE: verbosity level. 1 shows every command that is run and every Go package that is processed. 2 also shows subcommands and environment. The default value is 0, don’t be verbose.

`go-lint.sh`: Run backend static analyzers

Optional environment:

  • EXIT_ON_ERROR: if set to 0, don’t exit the script after the first encountered error. The default value is 1.

  • GO: set an alternative name for the Go compiler.

  • VERBOSE: verbosity level. 1 shows every command that is run. 2 also shows subcommands. The default value is 0, don’t be verbose.

`go-test.sh`: Run backend tests

Optional environment:

  • GO: set an alternative name for the Go compiler.

  • RACE: set to 0 to not use the Go race detector. The default value is 1, use the race detector.

  • TIMEOUT_FLAGS: set timeout flags for tests. The default value is --timeout=30s.

  • VERBOSE: verbosity level. 1 shows every command that is run and every Go package that is processed. 2 also shows subcommands. The default value is 0, don’t be verbose.

`version.sh`: Generate And Print The Current Version

Required environment:

  • CHANNEL: release channel, see above.

`snap/`: Snapcraft scripts

`build.sh`

Builds the Snapcraft packages from the binaries created by download.sh.

Optional environment:

  • SNAPCRAFT_CMD: Overrides the Snapcraft command. Default: snapcraft.

`download.sh`

Downloads the binaries to pack them into Snapcraft packages.

Required environment:

  • CHANNEL: release channel, see above.

`upload.sh`

Uploads the Snapcraft packages created by build.sh.

Required environment:

  • SNAPCRAFT_CHANNEL: Snapcraft release channel: edge, beta, or candidate.

  • SNAPCRAFT_STORE_CREDENTIALS: Credentials for Snapcraft store.

Optional environment:

  • SNAPCRAFT_CMD: Overrides the Snapcraft command. Default: snapcraft.

`translations/`: Twosky Integration Script

Usage

  • go run ./scripts/translations help: print usage.

  • go run ./scripts/translations download [-n <count>]: download and save all translations. n is optional flag where count is a number of concurrent downloads. Note, that it downloads locales for all configurations in the .twosky.json file.

  • go run ./scripts/translations upload: upload the base en locale.

  • go run ./scripts/translations summary: show the current locales summary.

    [!NOTE]
    The following script may produce false positives because JavaScript uses template literals like servicesgroup.${group.id}.name, so the actual key won't be found by substring search.

  • go run ./scripts/translations unused: show the list of unused strings.

  • go run ./scripts/translations auto-add: add locales with additions to the git and restore locales with deletions.

After the download you’ll find the output locales in the configured directory.

Optional environment:

  • DOWNLOAD_LANGUAGES: set a list of specific languages to download. For example ar be bg. If it set to blocker then script will download only those languages, which need to be fully translated (de en es fr it ja ko pt-br pt-pt ru zh-cn zh-tw).

  • UPLOAD_LANGUAGE: set an alternative language for upload.

  • TWOSKY_URI: set an alternative URL for download or upload.

  • TWOSKY_PROJECT_ID: set an alternative project ID. The default value is home.

`companiesdb/`: Whotracks.me database converter

A simple script that downloads and updates the companies DB in the client code from the repo.

Usage

sh
sh ./scripts/companiesdb/download.sh

`blocked-services/`: Blocked-services updater

A simple script that downloads and updates the blocked services index from AdGuard’s Hostlists Registry.

Optional environment:

  • URL: the URL of the index file. By default it’s https://adguardteam.github.io/HostlistsRegistry/assets/services.json.

Usage

sh
go run ./scripts/blocked-services/main.go

`vetted-filters/`: Vetted-filters updater

Similar to the one above, a script that downloads and updates the vetted filtering list data from AdGuard’s Hostlists Registry.

Optional environment:

  • URL: the URL of the index file. By default it’s https://adguardteam.github.io/HostlistsRegistry/assets/filters.json.

Usage

sh
go run ./scripts/vetted-filters/main.go

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#adblock Browse adblock catalog → #adguard Browse adguard catalog → #dns Browse dns catalog → #dns-over-https Browse dns-over-https catalog → #dns-over-quic Browse dns-over-quic catalog → #dns-over-tls Browse dns-over-tls catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →