$ show AdguardTeam/AdGuardHome
AdGuard Home is a production-grade, self-hosted network-wide ad/tracker blocking DNS server. In operation it listens for DNS queries, applies filtering via blocklists, custom rules, parental control, safe search, and DNS rewrites, forwards remaining queries to upstream resolvers over plain DNS, DoT, DoH, or DoQ, and records query logs and statistics. It also includes a DHCP server for IPv4/IPv6, client identification through ARP/WHOIS/rDNS/DHCP/hosts files, TLS/encryption management, and a REST API documented in the openapi directory. The Go backend is a modular monolith organized into domain packages such as dnsforward, filtering, querylog, stats, dhcpd/dhcpsvc, home, and the new next/websvc, with heavy use of interfaces and OS-specific build tags for Linux, macOS, Windows, FreeBSD, and OpenBSD. The repository ships two frontends in parallel: a legacy React/Redux application under client/ and a newer SolidJS application under client_v2/, both built with webpack and backed by the same HTTP control API. Entry points include main.go for the stable product and main_next.go for an ongoing architectural rewrite. Configuration is stored in YAML and migrated through 34 schema versions using a dedicated migration framework. The codebase is extensively tested at both unit and end-to-end levels, and release packaging scripts cover many OS/arch targets. The presence of JSON tracker metadata and safe-search rule lists is operational data, not research artifacts; this is not a data pipeline or analytics repository. Primary data flows: DNS request -> dnsforward request handler -> client identity lookup -> filtering engine (urlfilter, custom rules, hosts) -> safe-search/rewrite handling -> upstream forwarding -> response; each query is written to a binary query log and aggregated into statistics. DHCP leases persist through JSON databases, and embedded datasets such as whotracksme metadata and blocked-services definitions support UI and filtering behavior. The largest current risk is the dual-frontend and dual-backend transition, which creates duplication and increases maintenance burden, but the core DNS/DHCP/filtering paths remain coherent and well-tested.
The LLM identified 4 files worth highlighting for reuse:
A generic sorted-map implementation providing deterministic key ordering and iteration. It is self-contained, belongs to a tiny algorithms package, and can be dropped into another Go project whenever stable map iteration is needed for serialization, configuration output, or API response ordering.
Atomic file-replacement helpers with Unix rename and Windows-specific fallbacks. They write to a temporary file, sync, then atomically move it into place, solving the recurring problem of crash-safe persistence for configs and databases. The component is isolated from product logic and directly reusable in any Go application.
A versioned configuration migration engine: each schema version has an upgrade function, and the migrator applies them in order to YAML configuration. Comprehensive test fixtures for versions 1 through 34 demonstrate how to evolve on-disk formats without data loss. This pattern is highly reusable for long-lived applications requiring backward-compatible config upgrades.
A generic filesystem walker that chains path predicates and patterns to discover files such as hosts files or configuration paths. It abstracts platform-specific path differences and is independent of AdGuard-specific business logic, making it a clean candidate for extraction into any file-scanning or configuration-discovery tool.