Cloudflare Tunnel in Practice: Expose Your Home Lab Without a Public IP

Got a NAS at home you wish you could access from anywhere? Self-hosting a blog but your ISP refuses to hand out a public IP? Want remote access to HomeAssistant without poking holes in your router?

The traditional answers are: rent a VPS as a reverse proxy, fight with dynamic DNS, or give up. Cloudflare Tunnel offers a fourth path: your internal service dials out to Cloudflare's network, and visitors reach you through that tunnel — no inbound ports, no public IP required, completely free.

This guide gets you from zero to your first published service in 30 minutes.

---

What Is Cloudflare Tunnel

The One-Sentence Explanation

cloudflared is a lightweight daemon that runs on your internal machine and opens a persistent outbound connection to Cloudflare's network. When external users hit your domain, requests land at a Cloudflare edge node first and travel back through the tunnel to your internal service.

What It Solves

Tunnel vs Port Forwarding vs Frp

---

Prerequisites

Three things before you start:

1. A domain managed by Cloudflare (NS records pointing to Cloudflare). If not yet, go to Cloudflare dashboard → Add a site and follow the NS change instructions.
2. A machine running the service you want to publish — your NAS, a Mac mini, a Raspberry Pi, or a Windows PC all work.
3. Outbound network access with TCP port 7844 open to Cloudflare. Almost every home network allows this by default.

---

Method 1: Remote Management (Dashboard, Recommended for Beginners)

This is the path Cloudflare now pushes — all configuration happens in the web console and cloudflared pulls it from the cloud.

Step 1: Create a Tunnel in Zero Trust

1. Cloudflare dashboard → left sidebar Zero Trust
2. Navigate to Networks → Tunnels
3. Click Create a tunnel
4. Pick Cloudflared as connector type, click Next
5. Give it a name (use the host name, e.g. home-nas), save

Step 2: Install cloudflared on Your Internal Host

The dashboard generates a one-line install command with a token baked in based on your OS — copy and run it.

Linux (amd64, apt family):

macOS (Homebrew):

Windows (PowerShell as Administrator):

Docker:

After install the tunnel status in the dashboard will flip to Healthy.

Step 3: Publish a Service (Public Hostname)

Open the tunnel detail page, switch to the Public Hostnames tab, click Add a public hostname:

Within 30 seconds https://nas.example.com will route from the public internet to your internal localhost:5000. HTTPS certificates are issued automatically by Cloudflare — zero manual config.

---

Method 2: Local Configuration (YAML, Recommended for Advanced Users)

If you want config in Git or need multiple services on the same host, local YAML is cleaner.

Step 1: Log In and Create the Tunnel

Step 2: Write the Config File

Create ~/.cloudflared/config.yml:

Step 3: Bind DNS and Run

---

Use Case: Move SSH onto the Tunnel

Public SSH gets brute-forced relentlessly. With Tunnel you can close the SSH public port entirely and only allow access through Cloudflare.

Server Side (Where You Connect To)

Add to your ingress config:

Client Side

Option A: Browser-Rendered Terminal (most convenient, requires Zero Trust application config)

Zero Trust → Access → Applications → Add → Self-hosted, pick ssh.example.com, application type SSH, then add an identity provider (GitHub / Google / corporate SSO). Now opening ssh.example.com in a browser drops you straight into a web terminal.

Option B: Local ssh Through cloudflared Proxy

Now ssh [email protected] works as if you were connecting directly.

---

Add an Access Layer: Zero Trust Access

Publishing a service isn't always enough — you probably don't want the whole internet to see your HomeAssistant login page. Zero Trust Access challenges users before they touch your application.

Configuration Steps

1. Zero Trust → Access → Applications → Add an application

2. Pick Self-hosted

3. Application domain: ha.example.com

4. Pick at least one identity provider (the default One-time PIN email works fine)

5. Add an Allow policy:

Save. Now anyone hitting ha.example.com gets stopped by Cloudflare first — they must complete an email PIN or OAuth login before reaching your service. Your internal application doesn't change at all.

---

Common Pitfalls

1. Tunnel Stuck on Inactive / Down

90% of the time it's blocked outbound. Test manually:

Timeout means your network blocks the port. Rare on home networks, common on corporate/school networks — ask IT to whitelist.

2. HTTPS Backend Returns 502

If the internal service is HTTPS with a self-signed cert (typical for HomeAssistant or Synology DSM), add to ingress:

3. WebSocket Connections Keep Dropping

Bump idle timeouts:

4. Multiple Tunnels on the Same Host Conflict

cloudflared reads only one ~/.cloudflared/config.yml by default. For multiple tunnels, explicitly point to each config:

5. Docker Config Mount Locations

Remember credentials-file paths must reference the container path, not the host path.

---

Performance and Limits

---

Uninstall

If you ever want to back out:

---

Wrap-Up

Cloudflare Tunnel overturns the old assumption that you need a public IP to host anything. For solo developers and home-lab enthusiasts, it's almost a no-brainer:

• Zero cost — completely free
• Zero exposed ports — pure outbound, far safer than direct public hosting
• Zero certificate ops — HTTPS handled automatically
• Bonus protection — Cloudflare DDoS shield plus Zero Trust auth

The only "cost" is that your traffic flows through Cloudflare's network. For most self-hosting scenarios that trade is completely acceptable.

Next step: put every internal service in your home (NAS, blog, monitoring, IoT consoles) behind a single tunnel and use Access policies for per-service permissions. That's a modern zero-trust architecture for your home lab.