Home / Notes

DevOps · Cloudflare · Zero Trust

Zero Trust for the homelab: Cloudflare Tunnel and Access instead of open dashboards

An internal dashboard was publicly reachable via a subdomain. Here is how I locked it down with Cloudflare Tunnel, Cloudflare Access and Tailscale.

Serge Zabolotny · 2026-10-18

• Cloudflare Tunnel
• Zero Trust
• Cloudflare Access
• Tailscale
• Proxmox
• Homelab

Starting point

My homelab (Proxmox VE with LXC containers) runs a dashboard that lists all services. It was publicly reachable via a subdomain – without a login. That is exactly the typical gap in self-hosting: the service is handy, but anyone who guesses or finds the address sees the overview.

The solution in four building blocks

1. Cloudflare Tunnel as the only entrance. The tunnel makes an outbound connection to Cloudflare. So no port forwarding is needed on the router and no ports are open to the outside.
2. Cloudflare Access as the zero-trust layer. An Access policy sits in front of the dashboard: only my email address may enter, and sign-in works via one-time PIN.
3. Tailscale for everything private. Services that should never be public (e.g. photo management) are reachable only through the WireGuard-based Tailscale network.
4. Regularly check what is published. The actual trigger was a forgotten publication.

How I check what is really public

The key lesson: it is not only the service that counts, but also what DNS and the tunnel publish. My checklist:

• In the Cloudflare dashboard under Zero Trust → Tunnels: which Public Hostnames are registered?
• Under Access → Applications: does every public hostname have a policy?
• In the DNS records: are there old CNAME records pointing to services that no longer exist?

cloudflared tunnel list
cloudflared tunnel info <tunnel-name>

Result

The dashboard is now reachable only after login, no port is open on the router, and private services live entirely inside the Tailscale network. One dashboard less that gives away the internal infrastructure.

Keep reading