Cloudflare Tunnels: Expose Services Without Port Forwarding

If you've ever tried to expose a homelab service to the internet, you know the drill. Log into your router, fumble through the port forwarding settings, hope your ISP isn't blocking the port, pray you didn't just open a security hole, and then deal with dynamic DNS because your IP changes every few days.

There's a better way. Cloudflare Tunnels let you expose your services without opening a single port on your firewall. No port forwarding, no exposed IP address, no headaches. Let's dive into how it works and when you should actually use it.

What Are Cloudflare Tunnels?

Cloudflare Tunnels (formerly called Argo Tunnels) create an outbound-only connection from your server to Cloudflare's edge network. Instead of the internet connecting to you, you connect to Cloudflare, and they handle routing traffic to your services.

Think of it like this: rather than opening your front door and hoping only friendly visitors show up, you're hiring a security guard who meets everyone at the street and escorts the legit ones to your door. Your door stays locked the whole time.

The tunnel runs via a lightweight daemon called cloudflared. It maintains persistent connections to Cloudflare's network, and when someone visits your domain, traffic flows through those connections to your local service. All traffic is encrypted, and your origin IP stays completely hidden.

Tunnels vs Traditional Reverse Proxy: When to Use Which

Before you go all-in on tunnels, let's talk about when they make sense versus a traditional setup with something like Nginx Proxy Manager or Traefik.

Use Cloudflare Tunnels When:

• You're behind CGNAT. If your ISP uses carrier-grade NAT, you literally can't port forward. Tunnels are your only realistic option without paying for a VPS.
• You want zero exposed ports. Some people just sleep better knowing nothing is listening on their public IP. Fair enough.
• You don't have a static IP. No more messing with dynamic DNS services. Cloudflare handles it all.
• You want Cloudflare's security features. DDoS protection, WAF rules, and bot management come along for the ride.
• You're exposing services to others. Sharing a Jellyfin server with family? Tunnels make this dead simple and secure.

Stick with Traditional Reverse Proxy When:

• You need raw performance. Tunnels add latency since traffic routes through Cloudflare. For LAN-heavy usage, this matters.
• You're running non-HTTP services. Tunnels work best with HTTP/HTTPS. You can do TCP/UDP, but it requires a paid plan and more setup.
• You want full control. Some folks don't love routing all their traffic through a third party, even one as reputable as Cloudflare.
• You're already comfortable with port forwarding. If your current setup works and you understand the security implications, no need to change.

Personally, I run a hybrid setup. Internal services stay behind a local reverse proxy, while anything I need to access remotely goes through a tunnel. Best of both worlds.

Setting Up Your First Cloudflare Tunnel

Enough theory. Let's get a tunnel running. I'll assume you already have a domain on Cloudflare. If not, go add one first (free tier works fine).

Step 1: Install cloudflared

The cloudflared daemon is available for pretty much every platform. On Debian/Ubuntu:

# Add Cloudflare's GPG key
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null

# Add the repository
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list

# Install
sudo apt update && sudo apt install cloudflared

On Docker, you can skip this and run the container directly (more on that in a bit).

Step 2: Authenticate with Cloudflare

cloudflared tunnel login

This opens a browser where you select which domain to authorize. After you pick one, a certificate gets saved to ~/.cloudflared/cert.pem. Guard this file. Anyone with it can create tunnels on your account.

Step 3: Create a Tunnel

cloudflared tunnel create homelab

Replace "homelab" with whatever name you want. This generates a tunnel ID and credentials file. You'll see output like:

Tunnel credentials written to /home/user/.cloudflared/abc123-def456.json
Created tunnel homelab with id abc123-def456-ghi789

Step 4: Configure Your Tunnel

Create a config file at ~/.cloudflared/config.yml:

tunnel: abc123-def456-ghi789
credentials-file: /home/user/.cloudflared/abc123-def456.json

ingress:
  - hostname: jellyfin.yourdomain.com
    service: http://localhost:8096
  - hostname: homeassistant.yourdomain.com
    service: http://localhost:8123
  - service: http_status:404

The ingress section maps hostnames to local services. That last line is a catch-all that returns 404 for unmatched requests. You need it or cloudflared will complain.

Step 5: Create DNS Records

cloudflared tunnel route dns homelab jellyfin.yourdomain.com
cloudflared tunnel route dns homelab homeassistant.yourdomain.com

This creates CNAME records pointing to your tunnel. You can also do this manually in the Cloudflare dashboard if you prefer clicking over typing.

Step 6: Run the Tunnel

cloudflared tunnel run homelab

Your services are now accessible! Hit your subdomain and watch the magic happen.

Step 7: Run as a Service

You probably don't want to keep a terminal open forever. Install it as a systemd service:

sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

Now it starts automatically on boot and restarts if it crashes.

Docker Alternative

If you're running everything in Docker anyway, skip the system install:

docker run -d --name cloudflared \
  --restart unless-stopped \
  -v /path/to/config:/etc/cloudflared \
  cloudflare/cloudflared:latest \
  tunnel --config /etc/cloudflared/config.yml run

Or use the newer "quick tunnel" approach with a token from the Zero Trust dashboard. That's even simpler but gives you less local control.

Security Considerations

Tunnels are more secure than port forwarding by default, but they're not magic. Here's what to keep in mind:

Authentication Matters

Just because traffic goes through Cloudflare doesn't mean your services are protected. If your Jellyfin server has no password, anyone who guesses the URL can access it. Always configure authentication on your services.

For extra protection, enable Cloudflare Access. It adds an authentication layer in front of your tunnel, requiring users to log in before they even reach your service. You can use email OTP, Google, GitHub, or a bunch of other identity providers. The free tier gives you 50 users.

Keep cloudflared Updated

Like any software that handles network traffic, vulnerabilities happen. Set up automatic updates or at least check periodically. On Debian-based systems, unattended-upgrades handles this nicely.

Limit What You Expose

Don't tunnel your entire network just because you can. Each exposed service is attack surface. Be intentional about what needs internet access and what doesn't.

Monitor Your Tunnel

The Cloudflare dashboard shows tunnel metrics and logs. Check them occasionally. Unexpected traffic patterns could indicate someone poking around.

Understand the Trust Model

When you use tunnels, Cloudflare terminates TLS and can technically see your traffic. For most homelab use cases, this is fine. But if you're hosting something truly sensitive, understand that you're trusting Cloudflare as an intermediary.

Troubleshooting Tips

A few things that trip people up:

• 502 errors: Usually means cloudflared can't reach your local service. Check that the service is running and the port is correct.
• DNS not resolving: Make sure you created the DNS route. Check the Cloudflare dashboard for the CNAME record.
• Connection refused: If your service only listens on 127.0.0.1, cloudflared (especially in Docker) might not be able to reach it. Bind to 0.0.0.0 or use the host network.
• WebSocket issues: Some apps need WebSocket support. It should work by default, but check your service's compatibility.

Wrapping Up

Cloudflare Tunnels have genuinely changed how I think about exposing homelab services. The setup takes maybe 15 minutes, and then you never think about port forwarding again. Your firewall stays locked down, your IP stays hidden, and you get Cloudflare's protection for free.

Is it the right choice for everything? No. Performance-sensitive applications or non-HTTP services might be better served by other approaches. But for the typical homelab scenario of "I want to check my Home Assistant dashboard from work," tunnels are pretty much perfect.

Give it a shot. Your router's port forwarding page will thank you for the vacation.