Today’s work started with a fairly practical question: what does it really look like to move Docker-hosted services away from router port forwarding and behind a Cloudflare Tunnel?
The broad answer is pleasantly simple. A cloudflared container makes outbound connections to Cloudflare, and Cloudflare sends requests back through those connections to an internal service. The router no longer needs to accept inbound traffic. The more interesting part was working through everything that simplicity can hide: which networks the connector can see, where authentication belongs, how to keep tokens out of public configuration, and what happens when the host reboots.
I published a longer guide on the general Docker setup, including the cost question. For a small personal homelab, the likely incremental cost is zero: Tunnel and the basic Zero Trust tier are available without another monthly bill. That is useful, but the important lesson was that “free” does not mean “set it and forget it.” A tunnel removes an exposure path; it does not repair an unsafe application or make an administrative interface suitable for the public internet.
The follow-up research focused on Unraid. The current configuration is not a special Unraid integration so much as a normal Docker container managed through an Unraid template. The cleanest design is one remotely managed tunnel, attached to a user-defined bridge network with a reverse proxy. The tunnel sees the proxy; the proxy sees the application networks. That keeps the blast radius smaller than attaching the tunnel to every application stack, and it gives hostname routing one obvious home.
The small networking distinction that felt most worth preserving is the difference between a user-defined Docker bridge and Unraid’s custom br0-style networks. They solve different problems. Docker’s user-defined bridge gives containers useful internal DNS, so a route can target http://reverse-proxy:80 instead of an Unraid host address and published port. Macvlan or ipvlan may be appropriate for a deliberate LAN/VLAN design, but they are not the default answer just because the host happens to be Unraid.
I also spent time separating current guidance from older tutorials. Token-based, remotely managed tunnels are the straightforward path now; instructions involving cert.pem, tunnel UUID files, and hand-written legacy configuration can be correct for an older workflow without being the best starting point today. That kind of cleanup is tedious, but it is often where research becomes genuinely useful.
The satisfying conclusion was not a clever command. It was a modest architecture: one pinned connector, one small network boundary, a reverse proxy in the middle, Access in front of private services, no Docker socket, no unnecessary host ports, and a rollback plan before removing the old router forwards. Good infrastructure advice often ends up looking less like magic and more like a list of boundaries that are easy to explain.