Cloudflare Tunnels: Exposing Services Without Opening Ports (and the Trade-Offs)

There’s a particular dread that comes with port-forwarding something on your home router. You log into a web interface that hasn’t changed since the Blair government, you punch a hole through to a box on your LAN, and then you spend the next week wondering whether you’ve just invited the entire internet to find that one unpatched service. Carrier-grade NAT might mean you can’t forward ports at all, and a dynamic IP means you’re chasing DDNS updates on top of everything else. I have done all of this. I have also been the person discovering, via a logfile full of probes from a dozen countries, that an exposed service was rather more interesting to the internet than I’d hoped.

Cloudflare Tunnels — the thing formerly known as Argo Tunnel — offer a different deal. Instead of opening an inbound port, you run a small daemon called cloudflared that makes an outbound connection to Cloudflare’s network and holds it open. Traffic for your hostname arrives at Cloudflare, travels back down that existing tunnel to your daemon, and reaches your service. Your router’s inbound ports stay shut — there is, from the outside, no door to find. It feels like cheating, and for a homelab it’s frequently the right tool. But the trade-offs are real, and you should understand them before you commit your whole stack to a company you don’t pay and can’t phone.

The mental shift worth internalising is that this inverts the connection. Conventional remote access means something outside reaching in, which is exactly the posture port scanners and exploit kits are built to abuse. A tunnel means your box reaching out and a trusted intermediary stitching the two halves together. If you want a layer of identity behind that intermediary — proving which service is talking to which, rather than trusting the network — that’s a different tool with a different job, and it’s the one I reach for between internal services in mTLS without a service mesh. A tunnel gets traffic to your service; it doesn’t authenticate the service to its callers.

How the tunnel works

You install cloudflared on a box in your network and connect it to a named tunnel in your Cloudflare account. The daemon dials out to Cloudflare over HTTPS/QUIC and keeps that connection alive. Cloudflare then routes any request for your configured hostname back down the tunnel to the local service you’ve mapped it to.

1
2
3
4
5
6
7
8
9

tunnel: homelab
credentials-file: /etc/cloudflared/abc123.json

ingress:
  - hostname: grafana.example.com
    service: http://localhost:3000
  - hostname: jellyfin.example.com
    service: http://localhost:8096
  - service: http_status:404

Because the connection originates from inside your network, none of this requires a public inbound port, a static IP, or even a router you control. Run it on a Raspberry Pi behind CGNAT and it still works. That’s the headline feature, and it’s a genuinely good one.

The ingress block is evaluated top to bottom, first match wins, and that final catch-all returning http_status:404 is not optional decoration — it’s the rule that says “anything I haven’t explicitly mapped gets refused.” Leave it off and the daemon won’t start. I run cloudflared as a systemd service so it comes back after a reboot without my intervention:

1
2
3

sudo cloudflared service install
sudo systemctl enable --now cloudflared
journalctl -u cloudflared -f        # watch it connect and register its routes

A healthy tunnel logs four outbound connections to different Cloudflare edge locations — that redundancy is deliberate, so a single edge having a bad moment doesn’t drop your service.

What you get for free

On top of the no-ports trick, your traffic now rides Cloudflare’s edge. You get TLS termination with their certificates, so no Let’s Encrypt dance to manage yourself. You get DDoS absorption and a sensible web application firewall in front of services that were never written with hostile traffic in mind. Your home IP address never appears in DNS — visitors hit Cloudflare, not you — which removes a whole category of “someone found my home connection from a service I exposed” risk. And you can layer Cloudflare Access in front of any hostname to demand an email login or SSO before a single byte reaches your service, which is a genuinely lovely way to protect an admin panel that has no authentication of its own.

That last point deserves emphasis because it changes the security maths. Plenty of self-hosted tools ship with weak or optional authentication, on the assumption they’ll only ever be reached from a trusted LAN. The moment you expose one, that assumption is gone. Putting Access in front means an attacker has to get past Cloudflare’s identity layer before they can even reach the login page of the under-defended app behind it — defence in depth, achieved by configuration rather than code. It’s the closest thing to a free security upgrade in this whole space, provided you trust the gatekeeper.

1
2
3
4

cloudflared tunnel login
cloudflared tunnel create homelab
cloudflared tunnel route dns homelab grafana.example.com
cloudflared tunnel run homelab

Four commands and a config file, and your internal Grafana is reachable on a clean HTTPS URL with your home IP nowhere in sight.

The trade-offs nobody puts on the marketing page

Now the honest part, because this is not free in the ways that matter.

You are routing everything through Cloudflare. They terminate your TLS, which means they can see your traffic in cleartext at the edge. For a media dashboard, fine. For anything genuinely sensitive, that’s a meaningful trust decision, not a footnote.

Streaming large media through the proxy is restricted. Cloudflare retired the old “section 2.8” HTML-versus-non-HTML wording in 2024, but the underlying limit on the free CDN survived the rewrite: video and large files served through the proxy are restricted unless they’re hosted on a Cloudflare service like Stream, Images or R2. Self-host Jellyfin or Plex through a tunnel for the family and you’re squarely in the territory their terms restrict. People do it; people also get throttled or asked to stop. Read the current Self-Serve terms yourself rather than trusting a forum post from three years ago — the wording has genuinely changed.

It’s a single vendor with a single point of failure. When Cloudflare has a bad day — and they have had a few notable ones — so do you, and you have zero recourse. Your homelab’s availability is now bolted to a company you don’t pay and have no contract with. For a hobby dashboard that’s an acceptable risk. For anything you actually depend on, it’s a dependency you’re taking on with open eyes. And note the irony: you can build all the local high availability you like — I covered exactly that with keepalived and virtual IPs — but if every request still funnels through one external provider’s edge, your real availability ceiling is theirs, not yours. The tunnel quietly relocates your single point of failure off your network and out of your control.

They can see your decrypted traffic. This bears repeating in its own bullet because it’s the trade-off people most often wave away. TLS terminates at Cloudflare’s edge, so in the cleartext window between their edge and your origin, your traffic is visible to them. End-to-end it is not. If that’s disqualifying for a given service, a tunnel is the wrong tool for that service.

TCP and UDP are second-class. HTTP is the happy path. SSH, RDP and game servers are possible but fiddlier, often needing the WARP client on the other end rather than a plain browser, and the experience is noticeably less polished than the web case.

When it doesn’t work: troubleshooting

Tunnels fail in a small number of recognisable ways, and the daemon’s own logs (journalctl -u cloudflared -f) usually name the culprit.

• The hostname resolves but returns a 502 or 521. The tunnel is up; your service isn’t reachable from where cloudflared is running. Check the service: URL in your ingress config actually answers locally — curl http://localhost:3000 from the same box. A classic mistake is mapping to localhost when the daemon runs in a different container or namespace than the service, so “localhost” means two different things.
• A new hostname 404s. You added an ingress rule but didn’t create the DNS route, or you put the new rule below the catch-all http_status:404. First match wins, so a catch-all above your real rule swallows everything. Order matters; the 404 goes last.
• The tunnel won’t start at all. Usually a malformed config or a missing catch-all ingress rule — the daemon validates on startup and refuses to run with an invalid ingress block. The error is generally explicit about which line.
• It connects, then drops repeatedly. Your outbound firewall may be blocking QUIC (UDP 7844). cloudflared falls back to HTTPS over TCP if QUIC is blocked, but a flaky setup that half-allows it produces exactly this churn. Force the protocol with --protocol http2 to test whether QUIC is the problem.

When Access is in front of a hostname and you’re locked out of your own service, check the Access policy before blaming the tunnel — it’s almost always the policy, not the plumbing. And if you’ve stacked Access in front of an admin panel that also has its own auth, expect to log in twice; that’s working as intended, not a bug.

The verdict

For exposing a handful of web services — a dashboard, a notes app, a status page — from a network where you can’t or won’t forward ports, Cloudflare Tunnels are excellent, and the no-inbound-ports posture is a genuine security upgrade over poking holes in your router. I use one for exactly that, and pairing it with Cloudflare Access for admin interfaces is the kind of thing that used to take a VPN and an afternoon.

Who is it for? Someone with a few web services and either no ability to forward ports or no desire to, who values not having their home IP in public DNS, and who is comfortable with Cloudflare sitting in the path. That’s a lot of homelabbers, and for them it’s close to ideal. Who should think twice? Anyone running a media library through it, anyone who needs raw TCP as a first-class citizen, and anyone for whom a third party terminating their TLS is a dealbreaker. For those cases a self-managed alternative keeps the keys in your hands.

So: don’t make it the only way into your homelab, and don’t run your video library through it. If you need full control, raw TCP, or you simply don’t want a third party reading your decrypted traffic, a WireGuard tunnel to a VPS you control does the same no-open-ports trick with nobody else holding the keys. Use Cloudflare Tunnels where their strengths line up with your threat model — which, for the dashboard-and-notes-app crowd, is most of the time — and keep an honest second route home for everything that doesn’t fit.