Muslim
For many self-hosting enthusiasts, the journey begins with convenience. We set up our first server, struggle with port forwarding and CGNAT (Carrier-Grade NAT) constraints, and eventually stumble upon Cloudflare—the "holy grail" of free, reliable connectivity. For years, I viewed Cloudflare as the backbone of my digital infrastructure. It was the load-bearing pillar that held up my ingress traffic, DNS resolution, and remote access.
However, convenience often comes at the cost of control. Recently, I embarked on a personal experiment: a full-scale audit of my homelab dependencies. My goal wasn’t just to "de-Google" or "de-Cloudflare" for the sake of ideology, but to understand exactly where my data flows and why. What started as a simple effort to replace a single tunnel evolved into a complete re-evaluation of my technical stack.
Main Facts: The "Invisible" Infrastructure
The premise of my audit was simple: I wanted to own my entire ingress path. In the world of self-hosting, "owning your data" is the rallying cry, but many of us inadvertently delegate the "owning of the path" to third-party giants.
Cloudflare is undeniably powerful. For a user like myself—residing in rural India, where ISPs frequently employ CGNAT—Cloudflare Tunnel was a godsend. It allowed me to bypass the limitations of my residential network without the headache of static IPs or complex firewall rules. But as my lab grew, I realized that every external request to my servers terminated at Cloudflare. I was essentially renting a highway to my own house.
The audit revealed three distinct categories of dependencies:
- Critical Ingress: The pathways that let the internet reach my services (Tunnel).
- Foundational Services: The background utilities that facilitate my workflow (DNS-over-HTTPS, Mesh/Access).
- Platform Utilities: The static, high-value services that provide utility without imposing structural reliance (Pages, Workers, Global DNS).
Chronology of a Migration
The process of decoupling was not instantaneous. It was a methodical, three-phase operation that spanned several months.
Phase 1: The Tunnel Swap
The most daunting task was replacing Cloudflare Tunnel. I opted for Pangolin, a self-hosted alternative. The migration required a VPS—in my case, a Hetzner instance—to act as the middleman. Unlike the "plug-and-play" nature of Cloudflare, Pangolin required manual configuration and a deeper understanding of network architecture. While I successfully regained ownership of my ingress path, I learned a hard lesson about the "cost of freedom." Pangolin is free, but the VPS is not. Furthermore, it requires active maintenance, unlike the "set-it-and-forget-it" Cloudflare model.
Phase 2: The Accidental DNS Consolidation
My DNS transition was almost an afterthought. Previously, I ran Pi-hole and dnscrypt-proxy in tandem, with Cloudflare and Quad9 serving as upstream resolvers. During an attempt to simplify my stack, I migrated to AdGuard Home. This transition allowed me to consolidate multiple containers into one. As I shifted my upstream preference to Quad9, Cloudflare simply fell out of the chain. It was an invisible departure, proving that some dependencies are so deeply embedded we forget they are there until they are gone.
Phase 3: Moving from Mesh to Tailscale
The final hurdle was replacing Cloudflare Mesh for private, remote access. When I dropped Tunnel, keeping Mesh felt redundant. I transitioned to Tailscale, which leverages the WireGuard protocol. Because I was already behind CGNAT, traditional WireGuard setups were problematic, but Tailscale’s implementation bridged the gap seamlessly. The transition took a few hours of "muscle memory" re-configuration, but the result was a private network that I controlled end-to-end, without routing my private traffic through a third-party’s proprietary tunnel service.
Supporting Data and Technical Context
To understand the gravity of these changes, one must look at the technical trade-offs:
- Reliability vs. Sovereignty: Cloudflare’s infrastructure is arguably more reliable than my single VPS on Hetzner. By moving to a self-hosted tunnel, I introduced a single point of failure (my VPS). If the VPS goes down, my public services go dark.
- Complexity Metrics: My initial setup relied on two containers for DNS. My current setup relies on one. However, the management of the ingress tunnel has increased the number of "moving parts" in my configuration files by approximately 30%.
- Latency Considerations: In my testing, the latency shift between Cloudflare Tunnel and my Pangolin-based setup was negligible—often within the margin of error for residential fiber in rural India.
Official Perspectives and Industry Implications
While I am an individual user, the broader industry is currently wrestling with this exact "dependency fatigue." Major players in the open-source community, such as the maintainers of AdGuard and Tailscale, have long advocated for decentralized networking.
Industry analysts suggest that we are entering a "Post-Cloud" era for homelabbers. As companies like Cloudflare continue to expand their product offerings (Workers, D1, R2), the barrier to entry for self-hosting has lowered, but the "walled garden" effect has grown more pronounced. By choosing services that integrate deeply into their platform, users may find it increasingly difficult to migrate their data elsewhere. The implication for the future of the internet is clear: if we want a resilient, decentralized web, we must treat our infrastructure dependencies as carefully as we treat our personal data.
Implications: The "Intentional Dependency" Model
The most profound realization from this audit was not that all dependencies are bad, but that they must be intentional.
I chose to keep Cloudflare for domain management, DNS resolution, and global content caching (Pages/Workers). Why? Because replacing these with self-hosted alternatives offers minimal benefit while introducing immense overhead. A self-hosted DNS server is a fun project; a self-hosted global CDN is a nightmare that provides no real value to a home user.
Key Takeaways for the Homelabber:
- Audit Regularly: Once a year, map out every third-party service touching your homelab.
- Distinguish Needs vs. Wants: If a service solves a problem that you cannot reasonably solve yourself (like global latency reduction), it is an "earned" dependency.
- Complexity Budget: Never replace a working, low-maintenance tool with a complex, self-hosted one unless you are gaining significant control or privacy.
- The "Exit Strategy" Rule: Always ensure that if a provider were to disappear tomorrow, your data remains portable.
In conclusion, my experiment ended not with a 100% Cloudflare-free lab, but with a conscious one. I have stripped away the accidental dependencies that offered convenience at the cost of visibility, while retaining the foundational services that make the modern web possible. The lesson for every technologist is simple: true control is not about eliminating all dependencies; it is about knowing exactly which ones you have, and choosing them with your eyes wide open.
Asep Darmawan
