Cloudflare Tunnel for a self-hosted support site

Cloudflare Tunnel lets a machine with no public IP address and no open inbound ports, a home server, a NAS, a box sitting behind CGNAT, serve traffic to the internet anyway, by opening an outbound-only connection to Cloudflare instead of waiting for one to arrive. For this core use it is free, checked 22 August 2026 against Cloudflare's own announcement.

This page is one part of a larger guide. For the whole subject in one place, see self-hosting a feature request board.

What problem does Cloudflare Tunnel actually solve?

Most home internet connections, and a lot of small business ones, were never built to have anything served from them. Your router usually sits behind an IP address your ISP can change at any time, and increasingly behind CGNAT, where your ISP shares one public address across many customers and there is no inbound port to forward at all, whatever you configure on your own router. A support site running on a NAS in a cupboard, or on a spare machine at a desk, hits that wall immediately.

Cloudflare Tunnel solves it from the other direction. Instead of the internet reaching in to your machine, a small program on your machine reaches out to Cloudflare and keeps that connection open, and Cloudflare routes public requests for your hostname down through it. Your machine never needs a public IP, a static IP, or a forwarded port, because nothing is ever waiting for an inbound connection in the first place.

How is an outbound-only connection different from port forwarding?

Port forwarding works by telling your router "anything that arrives on port 443, send it to this machine on my network." Your router has to have a port genuinely open and listening, so anyone on the internet can attempt a connection to it, whether or not you sent them there. Every open inbound port is a door that has to be defended, patched and monitored, whether or not it is ever used by a real visitor.

A tunnel removes that door entirely. The connection is always initiated by your machine, outward, to Cloudflare. Nothing on your network listens for inbound traffic from the open internet, so there is no port for a scanner to find. That is a real security improvement, not just a convenience: it collapses your attack surface from "everything reachable on that port" down to "the tunnel software itself and whatever Cloudflare exposes on your behalf." It also means your home IP address is never exposed to a visitor, since every request actually terminates at Cloudflare.

How do you install and run cloudflared?

cloudflared is the program that opens and maintains the tunnel connection. It is a single binary for Linux, macOS and Windows, and for most home-server setups it runs as a background service so it survives a reboot without anyone starting it by hand.

On macOS, with Homebrew:

brew install cloudflare/cloudflare/cloudflared

On a Debian or Ubuntu-based Linux box, after adding Cloudflare's package repository:

sudo apt update && sudo apt install cloudflared

Once it is installed, authenticate it against your Cloudflare account and your domain:

cloudflared tunnel login

Then create the tunnel itself, which generates a unique tunnel ID and a credentials file:

cloudflared tunnel create support-site

How do you route a hostname to a local port?

A tunnel on its own does not know what it is supposed to serve. That comes from a small config file, usually ~/.cloudflared/config.yml, which points a hostname at whatever is running locally, in this case a support site listening on a local port:

tunnel: <tunnel-id>
credentials-file: /home/user/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: support.example.com
    service: http://localhost:3000
  - service: http_status:404

That last line matters: Cloudflare Tunnel requires a catch-all rule, so anything that does not match one of your named hostnames gets a plain 404 instead of falling through unhandled. With the config in place, the DNS record for that hostname is created with one command, pointed at the tunnel rather than at an IP address:

cloudflared tunnel route dns support-site support.example.com

From there, running it as a proper background service rather than a terminal window you have to keep open is one more command:

sudo cloudflared service install

At that point, a request to support.example.com reaches Cloudflare, travels down the existing outbound connection to your machine, hits the local port your support site is listening on, and the reply travels back the same way. Nothing on your network ever had to accept an inbound connection.

What are the honest limits of running a tunnel?

A tunnel adds a dependency a plain static deploy does not have. Your support site is reachable only for as long as three things are all true: your own machine is on, cloudflared is running, and Cloudflare's network is up. That third one is out of your hands, worth weighing against uptime, static versus hosted before committing a support site to a single home connection.

Your traffic also genuinely passes through Cloudflare's network, the same trade every visitor to a Cloudflare-protected site already makes, but it is worth being clear-eyed about rather than assuming a tunnel is somehow more private than a normal hosted deploy. And the free tier covers the tunnel connection itself, not everything Cloudflare sells around it: Argo Smart Routing, which picks faster paths across Cloudflare's own backbone for a fee, is a separate paid add-on.

Does a static support site need a tunnel at all?

Usually not, and it is worth saying so plainly rather than letting the appeal of the setup carry the decision. If a support site is just files, an index page, some blog posts, a changelog, there is no reason to keep a machine running at home to serve them: deploy the files to a static host or a CDN instead. See static site or server for that decision in full.

A tunnel earns its place when something genuinely has to keep running on hardware you control: a process that cannot be exported to a static host, data that must stay on your own machine, or a self-hosted tool with a real backend rather than a folder of HTML. There, a tunnel is a legitimately better answer than opening a port and hoping for the best.

Frequently asked questions