AdGuardHome Sync

Open-source DNS sync utility, honestly reviewed. If you’re running one AdGuard Home instance, close this tab. If you’re running two or more, keep reading.

TL;DR

• What it is: A companion daemon (Apache-2.0) that keeps one AdGuard Home instance’s configuration synchronized to one or more replica instances on a defined schedule [README].
• Who it’s for: Homelabbers and self-hosters running AdGuard Home on multiple nodes — a primary and at least one replica — who are tired of manually mirroring blocklists, rewrites, and DNS settings by hand [1][README].
• Cost savings: AdGuard DNS Premium runs $2.99–$5.99/mo for family plans. Commercial DNS filtering appliances run $50–$200/year. AdGuardHome Sync adds $0 to your existing self-hosted stack [README].
• Key strength: Solves exactly one problem extremely well: config drift between AdGuard Home instances. Docker-native, cron-driven, zero dependencies beyond the origin and replica AdGuard Home instances it manages.
• Key weakness: This is a utility, not a product. It has no UI of its own, no dashboards beyond a bare metrics endpoint, and its usefulness is entirely conditional on you already running AdGuard Home in a multi-node setup. 1,613 GitHub stars is respectable for a single-purpose sidecar tool — but don’t expect a thriving community forum if something breaks.

---

What is AdGuardHome Sync

AdGuardHome Sync is a small Go binary written by community developer bakito that reads config from a “origin” AdGuard Home instance and pushes it to one or more “replica” instances. That’s the entire product [README].

The problem it solves is mundane but genuinely painful: if you run AdGuard Home on two Raspberry Pis for redundancy — or across multiple Proxmox VMs, or across a primary homelab server and a remote VPS — every change you make on the primary (new blocklist, new DNS rewrite, new blocked service, new client rule) has to be manually reproduced on every replica. Miss a sync and your clients get inconsistent filtering behavior depending on which instance handles their query. AdGuardHome Sync automates away that friction [README][1].

The tool is written in Go, ships as a Docker image (quay.io/bakito/adguardhome-sync), a Homebrew cask, a binary for Linux/Mac/Windows, and as a systemd service. It communicates with AdGuard Home entirely through AdGuard Home’s existing REST API — there’s no agent to install on the AdGuard Home host, no schema changes, no patching [README].

DB Tech, a well-known homelab YouTuber, lists it explicitly in their 2024 self-hosting stack under “Maintenance” alongside Portainer and Watchtower — one of a handful of infrastructure tools they trust to run quietly and unattended [1].

At 1,613 GitHub stars and 50 forks, this isn’t a mass-market project. It doesn’t try to be. It’s the kind of tool that circulates through homelab communities precisely because it does one thing correctly and then stays out of your way.

---

Why people choose it

The pitch is simple and the alternative is worse. If you’re running redundant AdGuard Home instances — which is a common pattern for anyone who takes home DNS filtering seriously — your options without this tool are:

1. Manually sync configs every time you make a change. Meaning: log into instance A, make change, log into instance B, repeat. This fails in practice within a few weeks because humans forget.
2. Use a config management tool like Ansible to push AdGuard Home’s YAML config files to all hosts. This works but requires you to manage an Ansible playbook just to sync a DNS config, and it bypasses AdGuard Home’s API entirely, which can cause issues if the internal config format changes between versions.
3. Run only one instance and accept the single point of failure. Fine until your Pi dies and your entire home network stops resolving DNS.

AdGuardHome Sync replaces all three with a cron-driven daemon that uses AdGuard Home’s own API to sync defined feature categories: General Settings, Filters, Rewrites, Services, Clients, DNS Config, DHCP Config, and Theme. You decide which categories sync; each is individually toggleable [README].

The self-hosted DNS community has coalesced around this tool without a lot of debate. When Lemmy and Reddit threads surface asking what to self-host, AdGuard Home appears consistently in recommendations [2], and anyone running it at scale quickly discovers they need a sync layer. AdGuardHome Sync is the only serious open-source option in this specific niche.

---

Features

Core sync engine:

• Origin → N replicas sync on configurable cron schedule [README]
• Run-on-start option to sync immediately at daemon start, not just on cron fire [README]
• Per-feature enable/disable: you can sync filters without touching DHCP config, or sync rewrites without overwriting client settings [README]
• CONTINUE_ON_ERROR flag — sync continues if one replica fails, doesn’t abort the whole run [README]
• Configurable HTTP client timeout for slow/remote replicas [README]

Authentication:

• Username/password auth for both origin and each replica independently [README]
• Cookie-based auth as an alternative (useful if you’ve set up SSO in front of AdGuard Home) [README]
• Custom request headers per instance — covers setups behind reverse proxies with auth middleware [README]
• Per-instance TLS verification skip for self-signed certificates [README]

Auto-setup:

• New replica instances can be automatically initialized through the AdGuard Home setup wizard flow — the tool handles the initial install wizard programmatically so a fresh AdGuard Home container comes up pre-configured [README]

API and metrics:

• Exposes its own REST API on a configurable port (can be disabled by setting port to 0) [README]
• API supports basic auth [README]
• Prometheus metrics endpoint with configurable scrape interval and query log limit [README]
• TLS support for the API with cert/key directory configuration [README]
• Dark mode for the minimal API UI [README]

What it syncs (per-category toggles via environment variables or config file):

• FEATURES_DNS_ACCESS_LISTS
• FEATURES_DNS_SERVER_CONFIG
• FEATURES_DNS_REWRITES
• FEATURES_DHCP_SERVER_CONFIG
• FEATURES_DHCP_STATIC_LEASES
• General settings, filters, blocked services, clients [README]

What it does NOT do:

• It does not sync query logs or statistics — those are per-instance and remain independent
• It does not provide any DNS filtering itself — AdGuard Home does that; this tool only moves config around
• It does not replace AdGuard Home’s own backup/restore functionality for disaster recovery

---

Pricing: SaaS vs self-hosted math

AdGuardHome Sync is free. Apache-2.0 license, no tiers, no commercial edition [README].

The relevant cost comparison is what you’re replacing by running AdGuard Home (plus this sync tool) instead of a managed DNS filtering service:

Commercial DNS filtering alternatives:

• NextDNS: Free tier limited to 300K queries/month (a medium household blows through this). Paid plans start at $1.99/mo for 1 million queries. No multi-node HA by definition — it’s a cloud service.
• AdGuard DNS: The hosted version of the same ad-blocking tech. Personal plan: free with limits. Family plan: $2.99/mo (billed annually). Pro: $5.99/mo.
• Cisco Umbrella (enterprise DNS): $2.20+/user/mo — irrelevant for this audience but useful as a ceiling.
• Pi-hole managed hardware (like the Pi-hole Pro): Not a real product. Pi-hole is also free and self-hosted; the cost comparison there is just hardware.

Self-hosted math:

• AdGuard Home: $0 (GPL-3.0)
• AdGuardHome Sync: $0 (Apache-2.0)
• Two Raspberry Pi 4s for primary + replica: ~$70–$100 one-time hardware cost, or zero if you’re already running them
• Electricity: ~$3–6/year for two Pis at idle

Annual saving vs. AdGuard DNS Family: $35.88/year. Not dramatic, but the more important difference is data sovereignty — your DNS queries never leave your network [3].

If you’re comparing against NextDNS at $19.99/year (the “Plus” annual plan), the math flips: NextDNS is cheaper than hardware if you don’t already have Pis. The honest answer is that AdGuardHome Sync’s value proposition isn’t primarily cost — it’s control and HA within a stack you already decided to run.

---

Deployment reality check

AdGuardHome Sync is a sidecar to AdGuard Home, not a standalone product. You need AdGuard Home already running on at least two instances before this tool does anything useful.

What you need before installing:

• AdGuard Home set up and running on an “origin” instance (the one whose config wins) [README]
• At least one “replica” instance of AdGuard Home, also initialized through its setup wizard [README]
• Both instances reachable from wherever you run AdGuardHome Sync (can be on the same host as the origin, or on a separate container/VM) [README]

Installation options:

• Docker: docker run quay.io/bakito/adguardhome-sync — the common path for homelab setups [1][README]
• Docker Compose: the README provides compose examples; DB Tech runs it this way [1]
• Homebrew on Mac/Linux: brew install --cask adguardhome-sync [README]
• Binary: go install github.com/bakito/adguardhome-sync@latest or grab from releases [README]
• systemd: service file examples in the repo [README]

Minimum viable config (environment variables):

ORIGIN_URL=http://adguardhome-primary:3000
ORIGIN_USERNAME=admin
ORIGIN_PASSWORD=yourpassword
REPLICA1_URL=http://adguardhome-replica:3000
REPLICA1_USERNAME=admin
REPLICA1_PASSWORD=yourpassword
CRON=*/30 * * * *
RUN_ON_START=true

That’s a working setup. Everything else is optional tuning.

What can go sideways:

The tool has an FAQ and Deprecations wiki [README] — the existence of which signals there have been enough breaking changes and common questions to warrant it. Worth reading before deploying, particularly if you’re upgrading from an older version.

If your AdGuard Home instances are on different networks (e.g., primary at home, replica on a VPS), you’ll need to either expose AdGuard Home’s management port (3000 by default) to the internet — which is not recommended unprotected — or tunnel through Tailscale/WireGuard. This is a network architecture problem, not a problem with AdGuardHome Sync itself, but it’s a real deployment consideration that the README doesn’t spell out [README].

The auto-setup feature (initializing a fresh replica automatically) requires that the new AdGuard Home container be accessible on port 3000 during setup. If you’ve remapped that port or put it behind a proxy, you’ll need to account for that [README].

Realistic setup time for someone already running AdGuard Home: 15–30 minutes to add the sync container and verify it’s pushing configs correctly. If you’re setting up AdGuard Home for the first time and want sync from day one, budget an afternoon [3].

---

Pros and Cons

Pros

• Solves a real, specific problem. If you’re running multi-instance AdGuard Home, config drift is a genuine operational headache. This tool eliminates it without requiring you to adopt a full config management system [README][1].
• Apache-2.0 license. Permissive, no commercial use restrictions, embed it in whatever you want [README].
• Granular feature toggles. Syncing only rewrites and not DHCP config, or only filters and not client settings, is a one-line config change. Useful when replicas aren’t identical (e.g., different DHCP scopes per network segment) [README].
• Prometheus metrics out of the box. Plug it into your existing Grafana/Prometheus stack without additional setup [README]. Fits naturally into the monitoring toolchain that homelabbers running AdGuard Home typically already have [3].
• TLS and auth on the sync API. Not an afterthought — the tool’s own API supports cert-based TLS and basic auth [README].
• Auto-setup for new replicas. Spinning up a new AdGuard Home instance and having it configured automatically is genuinely useful for disaster recovery and node replacement scenarios [README].
• Actively maintained. 793 commits, working CI (Go build and e2e test badges in the README), renovate for dependency updates — not abandonware [README].

Cons

• Zero value for single-instance users. If you run one AdGuard Home instance, this tool does nothing for you. This review is irrelevant to most casual self-hosters [README].
• No UI for sync status. The minimal API shows you what it’s doing, but there’s no dashboard, no sync history log, no “last successful sync” indicator beyond what you’d scrape from Prometheus metrics. Debugging a failed sync means looking at container logs [README].
• Config drift detection is passive. The tool syncs on a schedule — it doesn’t watch for changes and sync immediately. If you change a blocklist on the origin and a DNS query hits the replica 10 seconds later, the replica hasn’t synced yet. Depending on your cron interval, you might see inconsistent filtering behavior between instances in that window [README].
• Limited community. 1,613 stars, 50 forks. Single maintainer project. If the maintainer stops updating it after an AdGuard Home API change, you’re either waiting, filing an issue, or patching it yourself. The FAQ/Deprecations wiki suggests this has happened before [README].
• Prerequisites are non-trivial. “Install this” assumes AdGuard Home is already running correctly on multiple instances, which itself assumes you have multiple nodes, working networking between them, and some Docker/Linux competency [README][3].
• Statistics and query logs don’t sync. If you’re using query logs for parental monitoring or traffic analysis, each instance maintains its own. You’d need a separate log aggregation layer (Grafana Loki, Graylog) if you want unified visibility [README].

---

Who should use this / who shouldn’t

Use AdGuardHome Sync if:

• You’re already running AdGuard Home on two or more instances and manually keeping them in sync (or letting them drift).
• You’ve set up AdGuard Home for high availability — primary and standby — and need config changes to propagate automatically.
• You’re running AdGuard Home on multiple network segments (home + office VPN, or home + VPS) and want consistent filtering everywhere.
• You’re comfortable with Docker and environment variables as a config interface.

Skip it (single instance is fine) if:

• You run one AdGuard Home instance and your threat model doesn’t include that instance going down.
• You’re just starting with self-hosted DNS filtering — get AdGuard Home stable before adding sync complexity.
• Your household is tolerant of intermittent DNS outages; a single Pi with a fallback DNS upstream (set in your router) is cheaper and simpler.

Skip it (use Ansible or another config management approach) if:

• You’re already running Ansible, Salt, or Puppet to manage your homelab infrastructure. Pushing AdGuard Home’s YAML config as a managed file is more consistent with your existing tooling than adding another sidecar daemon.
• You have more than a handful of nodes — at scale, a proper config management pipeline is more auditable than per-instance API calls.

Skip it (consider alternatives) if:

• You want unified management of multiple AdGuard Home instances through a single UI. AdGuardHome Sync has no UI; it’s a background daemon. There’s no “manage all instances from one place” interface — you still need to log into the origin instance to make changes [README].

---

Alternatives worth considering

• Pi-hole + Gravity Sync — if you’re running Pi-hole instead of AdGuard Home, Gravity Sync (https://github.com/vmstan/gravity-sync) is the equivalent project. Similar concept, different tool, Pi-hole specific.
• AdGuard Home’s native backup/restore — AdGuard Home has built-in backup/restore via its UI and API. For rare “disaster recovery” use cases, this is enough. For continuous sync between live instances, it’s too manual.
• Ansible playbooks — viable if you already manage your homelab with Ansible. Less elegant for rapid config iteration; more auditable for compliance-minded setups.
• NextDNS — if the HA requirement comes from paranoia about Pi downtime more than from genuine multi-site networking needs, a managed DNS service removes the ops burden entirely at low cost.
• Headscale + single AdGuard Home + Tailscale DNS — route all DNS queries through a single AdGuard Home instance over a WireGuard tunnel. Eliminates the multi-instance sync problem by eliminating the multi-instance architecture. More network complexity, less sync complexity.

---

Bottom line

AdGuardHome Sync is a narrow tool for a specific problem, and within that problem space it’s the best available open-source solution. If you’re running multiple AdGuard Home instances — which anyone serious about home DNS HA eventually does — manual config sync is the kind of operational friction that eventually breaks down. This tool replaces that friction with a cron job and a handful of environment variables. The Apache-2.0 license, Prometheus metrics support, and granular feature toggles make it more capable than its modest GitHub footprint suggests.

The honest caveat is that this is single-maintainer infrastructure software. It works today, the tests are green, and the project is actively maintained — but it’s not a backed company with a support contract. Run it, monitor it, and have a backup plan (literally: AdGuard Home’s native backup feature) for the day an API change breaks it.

If you’re running two Raspberry Pis for DNS redundancy and manually copying blocklists between them, the fifteen minutes to add this to your Docker Compose stack is obviously worth it. If you’re not running multiple instances, this review was never for you.

---

Sources

1. DB Tech Reviews — “What Am I Self-Hosting in 2024? (You Might Be Surprised By What You See!!)” — dbtechreviews.com. https://dbtechreviews.com/2024/04/30/what-am-i-self-hosting-in-2024-you-might-be-surprised-by-what-you-see/
2. Sopuli (Lemmy) — “What else should I self-host?” community thread — sopuli.xyz. https://sopuli.xyz/post/30242035
3. pidiylab.com — “AdGuard Home Raspberry Pi Setup with DoH, DoT & Parental Controls” — pidiylab.com. https://pidiylab.com/adguard-home-raspberry-pi-doh-dot-parental-controls/
4. Saltbox Docs — “AdGuard Home — Saltbox Documentation” — docs.saltbox.dev. https://docs.saltbox.dev/sandbox/apps/adguardhome/

Primary sources:

• GitHub repository and README: https://github.com/bakito/adguardhome-sync (1,613 stars, Apache-2.0 license)
• Docker image: https://quay.io/repository/bakito/adguardhome-sync
• Project wiki (FAQ & Deprecations): https://github.com/bakito/adguardhome-sync/wiki