Cloudflare Tunnel: exposing a service without opening a port

May 5, 2026

Picture this: you’ve got a beautiful, self-hosted photo library running on a server in your house. You want to pull up your photos from a friend’s place, or share a link with a family member. The old-school answer is to log into your router, open a port, and point your domain at your home IP. It works — and it exposes your home network to the internet in ways that should make you nervous.

There’s a better way.

What a Cloudflare Tunnel actually is

Cloudflare Tunnel (previously called Argo Tunnel) is a lightweight daemon — cloudflared — that you run on a machine inside your network. That daemon opens an outbound connection to Cloudflare’s edge. When a request comes in for your domain, it travels inward through that connection and gets handed off to your local service. The response takes the same path back out.

The key insight: you never open an inbound port. Your firewall can be as locked down as you like. From the outside, your home IP address is invisible — traffic terminates at Cloudflare, not at your router.

You install the daemon, authenticate it against your Cloudflare account, and define which internal address should back each public hostname. After that, cloudflared keeps the tunnel alive automatically.

The problem it solves

Running a homelab means running services you want to reach from outside your home. Maybe you want to check your home automation dashboard while traveling, pull up a recipe app from your phone at the grocery store, or share your self-hosted photo library with someone across the country. As soon as the use case extends past your front door, you need a plan for external access.

Before tunnels existed, the honest options were limited and each came with real tradeoffs:

Port forwarding is the classic move. Open a port on your router, point your domain at your home IP, and you’re done. It works, but your ISP’s IP shows up in DNS for the whole internet to see, your router’s attack surface is exposed to anyone who wants to probe it, and you need to wrangle TLS certificates yourself for anything that needs HTTPS. It’s manageable if you’re careful, but there’s ongoing maintenance and a real attack surface to worry about.

A VPN into your home network is more secure — only authenticated clients can reach anything inside. But it means every device you want to use needs a VPN client configured and connected, and inviting a family member to view shared photos becomes a whole IT project instead of sending a link. VPNs are excellent for personal access; they’re awkward for anything you want to share casually.

A cloud VPS reverse proxy gives you a stable IP and hides your home IP, but now you’re paying for and maintaining a server whose only job is to forward traffic. You’re managing two machines instead of one for a problem that should be simpler.

Cloudflare Tunnel sidesteps all three problems at once: no open ports, no exposed home IP, no extra server to provision, and links work for anyone with a browser — no client software required on their end.

What the commercial alternatives look like

It’s worth knowing what else exists in this space, because Cloudflare Tunnel isn’t the only answer.

ngrok is the developer tool most people encounter first. You run a command, get a public URL, and it works instantly — great for testing a webhook during development. The free tier gives you temporary URLs; persistent custom domains and multiple simultaneous tunnels require a paid plan. ngrok is fast to set up and genuinely useful, but it’s primarily aimed at developers testing local services rather than running them in production.

Tailscale Funnel is a newer option from the company behind Tailscale. Like the tunnel approach, it creates an outbound connection that makes a local service reachable from the public internet. Funnel is elegant if you’re already using Tailscale for device-to-device networking — it integrates naturally. The limitation is that it’s a newer feature with some rough edges, and it’s most useful when your whole network is already inside Tailscale.

Cloudflare Tunnel hits a different balance point: it’s free for personal use, has a mature production-grade daemon, integrates tightly with Cloudflare’s DNS (so you can point a subdomain at a tunnel in one step), and comes with optional bolt-ons like Access (authentication), WAF, rate limiting, and DDoS protection all in the same place. If you’re already running your DNS through Cloudflare — which many homelabbers do — the fit is natural.

Other paths worth knowing

If you’re evaluating approaches and tunnels feel like overkill, here are the alternatives worth understanding:

Port forwarding with a reverse proxy (like Caddy or Nginx Proxy Manager) is the traditional approach and it works fine if you accept the tradeoffs. You expose one port (443 for HTTPS), let the proxy route to the right service based on hostname, and manage certificates via Let’s Encrypt. Many experienced homelabbers run this way happily. The downside is that your home IP is in DNS and your router’s HTTPS port is open to the world.

Tailscale (without Funnel) is worth calling out separately. If you only need access for yourself and maybe a handful of people you trust, Tailscale creates an encrypted mesh VPN between your devices. You reach your homelab services by their Tailscale IPs or via MagicDNS. No public exposure at all. This is arguably the safest option — nothing is reachable from the internet unless a device is enrolled in your Tailnet.

WireGuard (self-hosted) is the low-level version of the same idea. WireGuard is a modern, fast VPN protocol; you run your own server, manage your own peer keys, and have complete control. The tradeoff is that it requires real networking knowledge to set up and maintain correctly. Tailscale is essentially WireGuard under the hood with all the management complexity abstracted away.

There’s no universal right answer. The choice depends on who needs access, how much you want to expose, and how much complexity you want to own.

How it fits a real homelab

In this lab, the tunnel runs as a persistent system service on a dedicated VM. It’s the single point through which all public-facing traffic enters — photo apps, the dashboard, automation tooling, and more. Everything flows through the tunnel; nothing on the router is open to the internet.

A few design choices worth calling out that apply generally:

Remote ingress configuration vs. local config. Cloudflare Tunnel supports two modes: locally configured (you define routes in a config file on the machine running cloudflared) and remotely configured (routes live in the Cloudflare dashboard and API). Remote configuration is generally more convenient — you can add or remove a public hostname without touching the server — but it means your local config file doesn’t control ingress anymore. This catches people off guard. If you edit your local config and nothing changes, check whether your tunnel is set to remote configuration mode.

The tunnel is additive, not required. For people who are home, on the local network, access should always work without going out through the tunnel and back in. The right approach is to configure your internal DNS resolver to point each public hostname directly to the local service IP. That way, the tunnel handles external access and local access is unaffected even if the tunnel is down. This keeps local performance fast and avoids an unnecessary roundtrip through Cloudflare’s edge just to reach a service five meters away.

Tunnel-down behavior. If the cloudflared daemon crashes or Cloudflare has an outage, external access disappears. Depending on how you use your lab, that might be completely fine — a homelab isn’t a production SLA. If you need more reliability, running two tunnel instances across different physical machines provides redundancy, since Cloudflare will load-balance between them automatically.

Cloudflare Access as a free authentication layer. One underused feature: you can put Cloudflare Access in front of any tunnel hostname and require authentication before traffic even reaches your service. Access supports email one-time-passcodes, GitHub OAuth, Google OAuth, and more. For services that don’t have their own strong authentication — or where you want an extra layer even on top of existing auth — this is powerful and costs nothing on personal plans. The authentication challenge happens at Cloudflare’s edge, so unauthenticated requests never touch your network at all. For sensitive tools like automation dashboards or administrative interfaces, this is a meaningful security upgrade with almost no setup cost.

What the daemon actually does when traffic arrives. It’s worth understanding the mechanics because they explain why this approach is so reliable. The cloudflared process maintains one or more persistent outbound connections to Cloudflare’s edge infrastructure. When a browser request comes in for your public hostname, it travels inward over that existing connection. The daemon looks up which local address should handle it, forwards the request, and passes the response back. Because the connection is outbound and persistent, there’s no need to punch through NAT or convince your ISP to cooperate — the tunnel just works on most residential connections without any router configuration at all.

Who should bother

Cloudflare Tunnel is worth your time if:

• You want to expose one or more homelab services publicly without touching your router
• You’re already using Cloudflare for DNS (the integration is frictionless)
• You want DDoS protection and TLS termination handled for you
• You have services that real humans need to reach via a link — family photo sharing, a calendar, a recipe app — not just yourself

You might skip it if:

• You only need access for yourself. Tailscale is simpler and doesn’t involve a third party in your traffic path.
• You have a static IP, you’re comfortable with port forwarding, and you don’t want to depend on Cloudflare’s availability. Nothing wrong with the direct approach if you know what you’re doing.
• You’re running something that absolutely cannot pass through a third party’s infrastructure. Cloudflare is seeing your decrypted traffic (since it terminates TLS at the edge). For most homelab use cases this is a fine tradeoff; for anything genuinely sensitive, factor it in.

Closing thought

The tunnel model represents a shift in how homelab networking gets done. A few years ago, opening a port was the obvious first step for external access. Today, the question is more often “do I need to expose anything at all, and if so, what’s the minimum surface?” Cloudflare Tunnel, Tailscale, and WireGuard each answer that question differently — and for many setups, the right answer is a combination: a VPN for personal access, a tunnel for shared links, and nothing else open on the router.

The goal isn’t to close the door on external access. It’s to choose exactly which doors exist and who has a key to each one.

← all posts