When someone asks me what the best tools are to start with when setting up a homelab. I always tell them that Cloudflare is by far the best service for homelabbers and the wider internet. Not because it was free, but because Cloudflare had quietly become the load-bearing layer of my homelab. From ingress to internal access and DNS resolution, I used Cloudflare for everything. Beyond these, Cloudflare services were sprinkled across my overall day-to-day workflow.

Once, I replaced Cloudflare Tunnel with self-hosted Pangolin, and when it actually worked, it became the first domino. I started looking at everything else Cloudflare was touching. My curiosity turned into a full audit of not only my homelab but also my broader workflow. In the end, what started as a simple replacement project led to a clear understanding of which Cloudflare dependencies were actually necessary and which could go.

I started with the tunnel, and it was the hardest swap I made

Free, invisible, and deeply uncomfortable

I adopted Cloudflare Tunnel, not because every other homelabber was doing it. It genuinely solved a major issue with the network while I was setting up my homelab for the first time. I live in the countryside of India, and even though I had some ISPs available, all of them were behind CGNAT. I had two internet connections, a wired fiber connection and a wireless air-fiber connection, and unfortunately, both of them were behind CGNAT.

Every self-hosted service I wanted to expose publicly needed a way in from the internet, and without a static IP, it was almost impossible to set up port forwarding and a reverse proxy. Even though I could manage private and local connections with some workarounds (more on that later), public access for services like Immich and Nextcloud was a nightmare. That’s when Cloudflare Tunnel came in. I deployed and configured everything in a couple of hours without any port-forwarding, public IP, or firewall headaches. And the best part for a budding homelabber, it was completely free of cost.

After many years with it, I realized that every external request entered my homelab through Cloudflare. All my ingress terminated at Cloudflare, and I didn't own that path. I wasn’t looking for an alternative because the tunnel failed me, or it suddenly became unreliable. But I wanted to understand what it would take to own the entire ingress path. That's when I decided to move to Pangolin, a self-hosted alternative to Cloudflare Tunnel.

Pangolin created a similar outbound-only tunnel from my home server to Cloudflare, but via a VPS in the middle. The initial Pangolin setup did take me on a bit of a detour, including the Nextcloud trusted domain issue I mentioned in my previous article. But once it was done, everything felt similar; the concepts were the same under different names. You might be thinking, "Why did I move from a free service to a paid one?" By ‘paid,’ I mean there's an indirect cost, the VPS it runs on. Pangolin was free, but it was not free to run. And why did I choose it? Because I already had a Hetzner VPS for another reason, I could host Pangolin at no extra cost. And I would finally own the whole ingress path.

The real question was what improved for me and what got worse? Starting with the good part. I finally owned and controlled the full ingress path end-to-end, and it was no longer dependent on Cloudflare’s tunnel infrastructure. I host Pangolin on Hetzner, but I'm not locked in. I can move it to any VPS whenever I want. Now for the honest part. Even though I was using my already rented VPS, it was still costing me something each month, whereas Cloudflare Tunnel was free. It became another component in my homelab to maintain; I couldn’t just set it up and forget it like Cloudflare.

I am still in transition, but I have already moved most of my public-facing services to Pangolin. And I intend to permanently drop Cloudflare Tunnel. Tunnel was the loudest Cloudflare dependency in my homelab. The next ones were much quieter, and I didn't even realize one of them had disappeared.

Two more Cloudflare dependencies. Two very different outcomes.

One left cleanly. One took some convincing.

Unlike Tunnel, these weren’t the dependencies I actively thought of throughout the day. One of them was never used directly, but it was sitting behind every DNS query on my network — DNS-over-HTTPS — and the other was something I only thought of when I needed that specific tool — private access to admin tools.

I was already running Pi-hole alongside dnscrypt-proxy, with Cloudflare and Quad9 DoH as the upstream resolvers. When the queries left my network, they were routed to Cloudflare or Quad9 for resolution. Cloudflare was simply sitting at the end of my DNS chain. It worked fine and rarely asked for attention. My initial mindset wasn’t even about replacing Cloudflare with any other public resolver, but that changed when I tried to simplify my DNS stack. I was maintaining two containers, Pi-hole and dnscrypt-proxy, for the same DNS tasks that AdGuard Home could do in just one container. So, it wasn’t a deliberate Cloudflare replacement, but rather a side effect of consolidating two DoH upstreams into one.

Once I moved to AdGuard Home, Quad9 became my upstream resolver, and Cloudflare quietly left the stack. I didn’t even notice it leaving because it had always been invisible, just one quiet component at the end of the chain, and I didn’t feel any noticeable downside. But the stack was reduced from two maintenance-required containers to one. I'm already testing Technitium to simplify the stack even further, but that's a story for another day. That migration was almost accidental. The next replacement was anything but.

I was using Cloudflare Mesh for private access to my internal services when I was away from home. Not because a better, more reliable one didn’t exist, but because I was already using Cloudflare Tunnel and Mesh was literally a few clicks away. When Mesh was already halfway configured, why would I take on the overhead of adding a new tool? So I intentionally used Cloudflare Mesh for my homelab. When I decided to drop Tunnel, Mesh felt like the natural next step, and Tailscale the best replacement.

The more I evaluated my infrastructure, the more Tailscale felt like a good fit. Actually, WireGuard would have been a better fit, but CGNAT didn’t allow me to do that. Tailscale was already using WireGuard under the hood without the setup overhead, so the decision was easy. The onboarding was painless. I created an account and set up my private network, called Tailnet. Then I installed the Tailscale client on all my devices under the same account, and everything was already on the same Tailnet network. It was more muscle memory changes than an actual learning curve. It took me a couple of hours to migrate my devices from Cloudflare to Tailscale, but after that, it became a one-click process again.

One dependency disappeared because another project made it unnecessary, and the other disappeared because I decided something else fit my workflow better. And by this time, most of the visible Cloudflare dependencies in my homelab were gone. What remained, I had no intention of replacing.

Some things I didn't even try to replace

Cloudflare earns these

Tunnel was the first Cloudflare service I used in my homelab infrastructure, but it was not the first Cloudflare service I used. I was using Cloudflare platform services even before I set up my home lab. I’d been using Cloudflare’s DNS and domain management long before my homelab existed. And later, other services like Pages, Workers, and Caching naturally became part of my workflow.

I use these platform services because they work, they’re reliable, and they’re mostly free or extremely inexpensive for my scale. And replacing them didn’t yield meaningful benefits — the alternatives didn’t solve a problem Cloudflare wasn't already solving.

When I started this experiment, the replacement felt like an obvious goal, but when it came to these services, I realized that dependency reduction doesn’t automatically translate to improvement. Some of the dependencies were accidental, and some of them were intentional. In the end, the real objective was simple: understand which dependencies were accidental and which were intentional.

When I entered self-hosting, my goal was maximum control of the services I used regularly, and most people are attracted to self-hosting for the same reasons. But after living with it for more than a year, I realized it also requires maintenance, and every replacement adds more complexity to the setup. If a service is providing value and running without any friction, replacing it for the sake of replacing makes little sense.

The experiment started as an attempt to make my homelab as Cloudflare-free as possible. But I learned a different lesson. Where Cloudflare earned its place, I kept it. Understanding my dependencies was the point, not eliminating them.

Not all dependencies deserve to be replaced

Cloudflare Tunnel was replaced by Pangolin, DoH disappeared during the DNS stack simplification, and Tailscale turned out to be a better fit. But I decided to keep platform services such as domain, DNS, Pages, Workers, and caching the way they were because they had earned their place. The lesson I learned from this whole experiment was that not all dependencies are equal. I picked up some because they felt convenient at the time, and others naturally added to my workflow because they provide real value and don't ask much in return.