← Networkingexpose a homelab service with zero open ports using cloudflare tunnel

expose a homelab service with zero open ports using cloudflare tunnel

$cloudflared tunnel run --url http://localhost:8080 homelab

why port forwarding is the thing nobody should default to

if you run a homelab, at some point you want to check your dashboard from outside the house, or let a friend hit your jellyfin server. the classic move is to go into your router and forward a port straight to that machine. the problem is the second you do that, your home ip is now advertised to the entire internet as "something is listening here." scanners find open ports in minutes, not days. you're not hiding in a crowd, you're the one house on the street with the porch light on and the door unlocked.

cloudflare tunnel flips the whole model. instead of opening a door for the internet to walk through, your server reaches out to cloudflare and keeps that connection open. nothing inbound ever touches your router. no port forward, no open firewall rule, nothing for a scanner to even see.

what "outbound-only" actually means

normally a service works like this: someone connects to your public ip on a specific port, your router forwards that traffic to a machine inside your network, and that machine answers. that requires an inbound rule, which is a hole in your perimeter that exists 24/7 whether you're using it or not.

a cloudflare tunnel works the opposite direction. the cloudflared daemon running on your server initiates a connection out to cloudflare's network and holds it open. when a visitor hits your domain, cloudflare routes that request down the existing outbound tunnel to your machine. your router never has to accept a new inbound connection because there isn't one. from the outside, your home ip just looks like a normal residential ip doing normal residential things. nothing to scan, nothing to fingerprint.

breaking down the setup

here's the flow and what each step is actually doing on your machine.

cloudflared tunnel login

this authenticates your machine against your cloudflare account and drops a certificate locally. it's the handshake that says "this device is allowed to create tunnels under my domain."

cloudflared tunnel create homelab

this creates a named tunnel called homelab and generates a unique tunnel id plus a credentials file. think of this as provisioning the actual outbound pipe before anything flows through it.

cloudflared tunnel route dns homelab app.yourdomain.com

this adds a dns record pointing your subdomain at the tunnel instead of at your home ip. notice what's missing here: your real ip is never published in dns. that alone kills a huge class of recon that depends on someone resolving your domain straight to your router.

cloudflared tunnel run --url http://localhost:8080 homelab

this is the part that actually does the work. it tells cloudflared "take traffic coming in on the homelab tunnel and hand it to whatever's running on localhost:8080." that local service never has to be exposed to your lan beyond localhost, let alone the internet. the tunnel is the only path in, and it's outbound by nature.

locking the front door with access

a tunnel gets rid of the open port problem, but it doesn't automatically mean "only me." if your service itself has weak or no auth, you've just made a weakly-protected app reachable from anywhere instead of unreachable. that's why step five matters just as much as the networking part.

cloudflare access sits in front of the tunnel and forces an identity check, like your google or github login or a one-time code, before the request ever reaches your service. this means even if someone finds your subdomain, they hit a login wall tied to your identity provider, not your app's possibly-weak default auth. for anything that doesn't have solid built-in authentication, access is the difference between "exposed to the internet" and "exposed to the internet and actually protected."

the takeaway

the real lesson here isn't "use cloudflare tunnel," it's understanding why inbound exposure is the risk in the first place. every open port is a standing invitation, used or not. flipping to an outbound-only model means there's nothing for a scanner to find on your home ip, and layering an identity check on top means even the thing that is reachable isn't reachable by just anyone. go check your own router right now. if you've got inbound rules forwarding to a homelab box, that's your actual todo list for this weekend.

watch the reel ↗
the weekly drop

one command a week that makes you harder to hack.

a single tool, explained in plain english, every week. straight to your inbox.

no spam. one email a week. unsubscribe anytime.