AdGuard Home started as a simple DNS filtering experiment for one computer. After trying a hosted DNS filtering option, I moved back to self-hosted AdGuard because I wanted more control over customization, device behavior, and troubleshooting.
It now runs as part of the core lab. Local devices use it through the network, and remote devices can use it through the private overlay network. That makes it useful, but it also means DNS is no longer a side project. When DNS is slow or unavailable, everything feels broken.
What Changed
- AdGuard moved from a personal-device experiment to a network-level service.
- It became the default DNS path for local and private-overlay devices.
- It is also configured through Tailscale DNS so remote personal devices can use the same filtering path away from home.
- It is backed up with the Proxmox LXC backup workflow.
- Snapshots can be taken before updates.
- Updates are applied deliberately instead of immediately, unless a security issue makes the update urgent.
Tuning Lessons
Running DNS through remote access exposed small delays that were easy to feel. Parallel upstream requests, HTTPS upstream DNS, IPv6 handling, and cache sizing all mattered more than expected. Increasing cache size made resolution feel noticeably better.
False positives are still part of the work. Some apps do not behave well when telemetry or tracking domains are blocked, so allowlisting and troubleshooting are part of keeping the service useful.
Operating Lesson
The operational lesson is the useful part: DNS filtering is simple until every device depends on it.
That is why this service stays intentionally boring. It is useful enough to be core infrastructure, so the goal is not to make DNS clever. The goal is to keep it fast, backed up, easy to update, and understandable when something feels slow.