{"id":23684,"date":"2026-07-22T18:45:35","date_gmt":"2026-07-22T17:45:35","guid":{"rendered":"https:\/\/innovatenews.site\/index.php\/2026\/07\/22\/i-already-replaced-cloudflare-tunnel-with-pangolin-then-tailscale-funnel-almost\/"},"modified":"2026-07-22T18:45:43","modified_gmt":"2026-07-22T17:45:43","slug":"i-already-replaced-cloudflare-tunnel-with-pangolin-then-tailscale-funnel-almost","status":"publish","type":"post","link":"https:\/\/innovatenews.site\/index.php\/2026\/07\/22\/i-already-replaced-cloudflare-tunnel-with-pangolin-then-tailscale-funnel-almost\/","title":{"rendered":"I already replaced Cloudflare Tunnel with Pangolin, then Tailscale Funnel almost\u2026"},"content":{"rendered":"
\n

The topic I already replaced Cloudflare Tunnel with Pangolin, then Tailscale Funnel almost\u2026<\/strong> is currently the subject of lively discussion \u2014 readers and analysts are keeping a close eye on developments.<\/p>\n

This is taking place in a dynamic environment: companies\u2019 decisions and competitors\u2019 reactions can quickly change the picture.<\/p>\n

I had previously talked about how I ditched Cloudflare Tunnel for self-hosted Pangolin. It was all fine; Pangolin was working. So, theoretically, case closed, right? While I was working on a Tailscale experiment, I coincidentally came across Tailscale Funnel. It was just a command on the terminal, and a final live URL came out the other end. The pitch \u2014 no reverse proxy, no DNS records, no certs, no port forwarding \u2014 made me rethink my Pangolin setup. That was when I decided to move a few services to Funnel. At first, it felt like I\u2019d over-engineered my setup, but that feeling didn\u2019t last long.<\/p>\n

Tailscale is easy to set up, but is that trading off your security?<\/p>\n

The DNS and external access parts of my homelab had been a rollercoaster. DNS is another day\u2019s topic; let’s talk about external access. I, like everyone, started with Cloudflared. Easy implementation and a no-brainer choice for a budding homelabber. And gradually moved to all Cloudflare \u2014 Tunnel, Mesh, and DNS. Then I finally moved to Pangolin for external public access and Tailscale for external private access because I didn\u2019t like keeping all my eggs in one basket.<\/p>\n

I had been using Pangolin for a month, and everything was going well, as expected. It was a stable setup, but it wasn\u2019t invisible. I was still maintaining things like Traefik, DNS records, the dashboard, occasional maintenance, and on top of it, a small but recurring VPS bill. But I was still happy with the setup. Then, last week, while writing an article about how Tailscale helped me avoid paying my ISP for a static IP, I coincidentally discovered Funnel. That discovery made me question my whole setup.<\/p>\n

I took a quick look at the features, and the appeal was almost absurd \u2014 no reverse proxy, no DNS, no SSL certs, and no port forwarding. It was just two commands \u2014 tailscale serve and tailscale funnel \u2014 and it would give me a public URL that worked even for people outside my tailnet. It made me think, if it were this simple, why was I even running Pangolin? That was when I decided to give it a try: I would either temporarily pause my Pangolin setup for a week or migrate a few services to Funnel for real-world testing.<\/p>\n

I started with the Tailscale serve and tailscale funnel commands but got the \u201cthe CLI for serve and funnel has changed\u201d error message. After going through the new docs, I switched to the new syntax. Since it was my first time using Funnel on that account, it asked me to enable Funnel on that tailnet. It was basically a direct browser link with a one-click approval process. Once done, I reran the command with Immich localhost on port 443.<\/p>\n

\"\"<\/figure>\n

It instantly gave me a live public URL; I immediately opened it on my device outside my tailnet. Immich loaded instantly. It was only one command, not the two I’d assumed \u2014 and I already had a live URL. After that, I started thinking \u2014 I’d spent so much time replacing Cloudflare Tunnel with Pangolin, and now a completely different tool seemed to remove the need for most of that work. It made me wonder whether I\u2019d over-engineered my own homelab.<\/p>\n

After Immich worked flawlessly, I thought of moving more services to it. That’s when the honeymoon ended.<\/p>\n

A WireGuard-based mesh VPN that connects all your devices privately, no port forwarding or public exposure needed.<\/p>\n

Immich worked so well that it didn\u2019t feel like a test anymore; I genuinely wanted to move more services to it. I wanted to move the majority of my services from Pangolin to Funnel, as a proof of concept. While browsing through the docs, I didn\u2019t read the line properly but saw it mentioned ports 443, 8443, and 10000. So, I used the same ports while enabling Funnels. Immich was already enabled on port 443, so I used the other two for Uptime Kuma and ntfy.<\/p>\n

Both of them worked. Both commands gave me live public URLs, and those worked properly too. Then I tried another service, but on port 9000. It created the funnel, but the URL didn’t work. It constantly gave me the ERR_CONNECTION_TIMED_OUT error. I disabled the funnel and reran it; still the same error. It was surprising that the CLI didn\u2019t give me errors while creating, but it never worked on the browser. That was when I decided to recheck the docs. And the line I previously ignored was \u201cFunnel can only listen on ports 443, 8443, and 10000.\u201d It made everything clear and worse at the same time.<\/p>\n

When I created the funnel on port 9000, the CLI just created it and never validated the port. But when I tried opening the link, Tailscale’s actual public-facing relay infrastructure silently drops anything outside 443, 8443, and 10000. At that moment, I realized that I’d filled all three slots without even trying very hard.<\/p>\n

So, I turned to a different device to host another service. I ran a similar command on my gaming PC.<\/p>\n

\"\"<\/figure>\n

It worked, but it gave me a new hostname. It made sense: a different node meant a different hostname. That was when I finally realized this wasn\u2019t a shared entry point, but every node became its own little island. With Pangolin, multiple backend machines can sit behind one public entry point.<\/p>\n

I could have lived with that, but the next issue was more concerning. I noticed every domain had the same structure: ..ts.net:port. It was kind of tough to remember and distribute. I checked the Tailscale dashboard to see if I could change this, but Tailscale Funnel strictly locked me into its ts.net domain structure I was used to more branded structures like photos..com and the ts.net hostname constantly reminded me that these services belonged to someone else’s namespace.<\/p>\n

I realized one thing after this experiment: Funnel wasn\u2019t broken. It wasn\u2019t built for the purpose I was expecting. It was built to solve a different problem altogether.<\/p>\n

I had the \u201cCan Funnel replace Pangolin?\u201d question when I started the experiment. And by the end \u2014 not even a full weekend \u2014 the question had changed to \u201cShould it?\u201d I had been treating both Pangolin and Tailscale Funnel as if they solved the same problem. But I eventually figured out they didn\u2019t.<\/p>\n

My architecture is categorically divided into two: public- and private-facing services. The public-facing services include Jellyfin, Immich, Nextcloud, Uptime Kuma, and other services that I distribute outside my home network. Everything else falls into the second category \u2014 Docker dashboard, internal tools, admin interfaces, and development services that I never intended to expose publicly.<\/p>\n

I had already been using Tailscale for the second category for a long time. And I think Funnel fits comfortably alongside Tailscale. A simple, direct exposure when I genuinely need it, without the overhead of my reverse proxy. So, for temporary work, I don\u2019t have to create a new service on Pangolin and set up DNS for it. I can just spin up a temporary Funnel, distribute it, and then disable it once the work is done.<\/p>\n

Instead of exposing everything through Pangolin, I’ve become more intentional about what actually deserves a public URL, which ultimately makes Pangolin’s job much cleaner. By the end of the experiment, I realized comparing Pangolin and Funnel was flawed to begin with. Both solve different problems, and they can run alongside each other.<\/p>\n

Self-hosted, open-source for exposing your own services under your own domain.<\/p>\n

Did Funnel replace Pangolin? No, the experiment didn’t send me back to Pangolin unchanged. It actually improved my setup and made me realize which services deserved a permanent public URL and which ones only needed a temporary one. I host a handful of services that are reachable from the open internet. And those services deserve their own domain, real routing, and room to scale, not the rest of them. I\u2019d started the experiment of trying to replace Pangolin. I ended up understanding why I’d installed Tailscale in the first place.<\/p>\n