DEV Community: Own The Stack

Block Ads on Every Device, Everywhere!

Own The Stack — Sun, 07 Jun 2026 13:07:57 +0000

Block Ads on Every Device, Everywhere

Most ad-blocking setups only work at home. You configure a DNS server on your router, enjoy a cleaner internet experience, then leave your Wi-Fi network and lose all of it. Your phone switches to mobile data, your laptop joins a coffee shop network, and suddenly you are right back to dealing with intrusive ads, trackers, telemetry requests, and analytics endpoints.

I wanted an infrastructure setup that followed me everywhere. Not just on my home network, and not just when connected to Wi-Fi. I needed it on every device, on every network, everywhere. This is how I built it using AdGuard Home and Tailscale—and why the simplest design ended up being the superior engineering choice.

What Is Tailscale?

Before diving into the implementation, it is worth understanding why Tailscale makes this architecture possible. Tailscale is a zero-config VPN built on top of the WireGuard protocol that creates a secure, private mesh network between all of your connected nodes, known as a Tailnet.

You can install it seamlessly on your laptop, phone, desktop, VPS, or home server. Once configured, they can securely communicate regardless of where they are physically located. Your phone on mobile data can route directly to your server at home, and your laptop in a coffee shop can securely reach a VPS in another country. Everything behaves as if it is sitting on the exact same local private network topology.

Each device on the mesh network receives a stable, private IP address in the 100.x.x.x range. Crucially for our use case, Tailscale allows you to centrally manage DNS settings for every single device connected to your Tailnet. Instead of configuring custom DNS servers separately across multiple operating systems, we configure it once in our Tailscale coordinator panel and let it distribute everywhere automatically.

Option 1: The Five-Second Setup

If all you want is robust ad blocking without running or maintaining any of your own compute infrastructure, AdGuard provides public DNS servers that can be integrated directly into your Tailnet.

To set this up, open your Tailscale Admin Console, navigate to DNS, and locate the Global Nameservers section. Add the following public upstream IP addresses:

94.140.14.14
94.140.15.15

Once added, toggle the Override Local DNS option to On. Every device connected to your Tailnet will immediately begin using AdGuard's public upstream resolvers for all outbound traffic.

For many users, this zero-maintenance approach is more than enough. However, the obvious downside is that you lose absolute control over your traffic. You cannot build custom blocklists, view granular query logs, write local DNS split-horizon overrides, or manage device-specific filtering rules. If you prefer owning your stack completely, self-hosting is the path forward.

Option 2: Self-Hosted AdGuard Home

Running a dedicated AdGuard Home instance gives you absolute data sovereignty and complete control over your network's DNS filtering layers. The computational footprint is incredibly lightweight. A minimal cloud VPS with roughly 512MB of RAM is plenty of overhead to handle a personal DNS server.

Deploying AdGuard Home Securely

Many standard deployment guides tell you to map ports directly out to the host using "53:53/udp". On Linux hosts, Docker manipulates iptables directly and completely bypasses standard host firewalls like ufw. This unintentionally exposes your DNS port to the public internet, making your VPS a prime target for weaponized DNS Amplification DDoS attacks.

To circumvent this risk completely, we can leverage Docker's host networking mode. This forces the container to share the host's network interfaces directly, allowing us to safely bind AdGuard Home exclusively to our private Tailscale interface during the initial configuration wizard.

Create your deployment file:

services:
  adguardhome:
    image: adguard/adguardhome
    container_name: adguardhome
    restart: always
    volumes:
      - ./adguard_data:/opt/adguardhome/work
      - ./adguard_conf:/opt/adguardhome/conf
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "3000:3000/tcp"  # This will be your permanent Admin UI port
      - "8080:80/tcp"    # This maps the setup wizard/web service to 8080
      - "853:853/tcp"   # DNS-over-TLS (optional but good for tech gadgets)

Run the stack in detached mode:

docker compose up -d

If the container refuses to bind or fails to start, an existing system service is likely already listening on port 53. The most common culprits on modern Linux distributions are systemd-resolved or dnsmasq. You must stop, disable, or reconfigure the conflicting service on the host before AdGuard Home can successfully claim the port.

Connecting AdGuard Home to Tailscale

Once the container is initialized, access the setup wizard by pointing your browser to your server's IP address at port 3000: http://YOUR_SERVER_IP:3000. Complete the prompts to establish your admin credentials and choose your interfaces.

With AdGuard up and running, it is time to link it globally to your network:

Open your Tailscale Admin Console and copy your VPS's private Tailscale IP (the 100.x.x.x address).
Navigate to the DNS configuration tab.
Under Global Nameservers, click Add Nameserver and choose Custom.
Paste your private server IP, save the configuration, and enable Override Local DNS.

Always use the Tailscale network interface IP rather than the server's public IP address. This guarantees that your raw DNS payloads travel strictly inside an encrypted WireGuard tunnel, completely isolated from the open internet. Your laptop, phone, tablet, and desktop will now route their lookups through your private instance, regardless of where you travel.

What DNS Blocking Can and Can't Do

DNS filtering is an incredibly effective tool, but it is not magic. It excels at dropping queries to known tracking domains, blocking background application telemetry, and filtering advertisements on platforms that do not support standard browser extensions.

However, it cannot reliably strip out video advertisements on platforms like YouTube, nor can it stop ads served directly from the same domain hosting the content. Think of network-level DNS filtering as an essential, high-performance first layer of defense rather than a complete alternative to client-side browser extensions like uBlock Origin.

The Operational Reality

There is an unavoidable architectural reality to this setup. If your self-hosted DNS server drops offline or the container panics, your internet access effectively breaks. Because almost every app and web page initialization begins with a synchronous DNS lookup, a failure here causes everything to fail in strange, silent ways.

Fortunately, your emergency exit playbook is simple: Turn off Tailscale. Disconnecting your client device from your Tailnet instantly drops the operating system back to the local network's native DNS configuration, bringing you back online immediately.

When encountering this reliability challenge, the immediate engineering instinct is to add a public fallback resolver like 1.1.1.1 in the Tailscale dashboard. However, this disrupts your filtering strategy entirely. Operating systems do not gracefully fail over; instead, they often query multiple configured nameservers in parallel or round-robin between them, causing ads to slip past your filter even when your server is completely healthy.

The Over-Engineering Rabbit Hole

You could build an enterprise-grade high-availability system to mitigate this risk. You could spin up redundant global nodes, synchronize configurations automatically using open-source sync tools, and manage complex internal load balancers.

But for a personal project, that introduces massive architectural complexity to solve a failure that might happen once a year. The management overhead of the infrastructure quickly outgrows the practical utility of the tool.

Approach	Control	Reliability	Complexity
Public AdGuard DNS	Low	High	Very Low
Self-Hosted AdGuard Home	High	Moderate	Low
Multi-Server Infrastructure	High	High	High

A cleaner, more pragmatic engineering tradeoff is keeping a single, hardened AdGuard Home instance backed by a clear recovery plan. Simple systems fail in highly predictable ways, require zero configuration synchronization, and are easy to maintain. Sometimes, owning the stack isn't about deploying the most complex distributed architecture—it is about knowing exactly where complexity pays for itself, and where it doesn't.

Why I Bypassed the Cloud Treadmill to Build a 100% Independent Self-Hosted Stack

Own The Stack — Fri, 05 Jun 2026 22:03:23 +0000

Philosophy doesn't mean much without execution. If I’m going to advocate for data sovereignty and owning your data, I need to show you exactly what my architecture stands on.

My project, OWNTHESTACK.co, isn't deployed to a massive managed web service, it doesn't use third-party serverless infrastructure, and it doesn't store media in an invisible corporate bucket. It runs entirely on an independent, flat-rate virtual private server (VPS) running minimal Linux.

Here is the exact containerized layout and setup powering the application.
The Design Philosophy

The goal: maximum control, absolute data ownership, and strict network privacy. The host operating system remains completely clean. Everything is modular, portable, and tightly locked down inside isolated internal container environments.

The Core Engine (.NET 8 & React)

The backend processing engine is a clean .NET 8 application. Modern .NET is incredibly fast, memory-efficient, and runs flawlessly inside isolated Linux containers. It handles text payloads and securely encrypted administration sessions. The frontend uses lightweight static production assets served with near-zero resource overhead.

Personal Data Control (PostgreSQL 16)

Every word of text, metadata tag, and background layout setting lives in a localized PostgreSQL 16 data engine running locally inside an isolated container with an explicit disk mount. Backups are raw, automated compressed files controlled by simple shell scripts that back up exactly what matters to an encrypted storage destination I control.

Independent Media Storage (MinIO)

Inline graphics don't stream from a generic public media host or a third-party asset SaaS. They stream straight out of a local MinIO storage vault container running on our hardware using secure, short-lived cryptographic links.

Reversing the Firewall (Cloudflare Tunnels)

This is the most critical privacy and security boundary. If you run an external network port scan on this server's public IP address, port 80 and port 443 are completely closed. Instead of opening the server to the wide-open internet and constantly fighting off automated bot scans, the server runs a secure outbound tunnel daemon. It establishes an encrypted, outbound-only pipeline to the network edge. Web traffic routes securely down this outbound pipe straight to our internal container environment. If it doesn't originate from this authenticated channel, it cannot touch our data.

I am documenting my entire journey of migrating off corporate platforms, sharing raw configs, and analyzing self-hosted infrastructure. Follow along or subscribe to the raw logs at OwnTheStack.co

What Am I Actually Depending On? A Practical Approach to Data Sovereignty

Own The Stack — Fri, 05 Jun 2026 21:57:47 +0000

Most of us don’t really own our digital lives.

Our photos live in cloud libraries. Our documents sit in someone else’s storage systems. Our passwords are managed by services we log into, not systems we control. It’s convenient, fast, and mostly invisible.

But at some point, I started asking a simple question: what am I actually depending on here?

The more systems I looked into, the more I realized how much personal data flows through platforms I don’t control. What gets stored, how it’s used, where it’s replicated, and who ultimately has access to it is often hidden behind terms of service most people never read. Convenience often comes with tradeoffs that are easy to ignore until they matter.
Thinking Differently About Data Management

I decided to evaluate where my information lives, how it’s backed up, how portable it is, and what happens if I ever want to leave a service. Not in an extreme way, but in a practical one: reducing dependency, increasing clarity, and keeping control where it matters.

I broke things. A lot of things. I rebuilt them. I migrated setups that didn’t scale. I replaced tools I thought I needed with simpler systems I could actually explain. And slowly, I started to care less about convenience at any cost, and more about understanding the ground I was standing on.

The goal isn’t to reject modern tools or pretend everything should be self-hosted. It’s to understand what we use well enough to choose it deliberately instead of passively accepting vendor lock-in.

Over the next few weeks, I’m putting out raw logs covering:

Self-hosting & app deployment

Data ownership & portability

Docker orchestration & Linux systems

Networking & outbound secure tunnels

Backups & monitoring

No schedules, no marketing noise. Just raw building, breaking, and learning what holds up. Check out the project architecture at ownthestack.co