Cloudflare Tunnel for local development

Why a tunnel

A local development server on localhost is only reachable from your machine. When you need a colleague to click your work-in-progress, or a service like a payment or social webhook must reach your local code, you need a public URL. The usual reflex is port forwarding on the router, which opens an inbound hole into your network. A tunnel avoids that.

Cloudflare Tunnel runs a lightweight daemon called cloudflared on your machine. It makes an outbound-only connection to the Cloudflare network, and Cloudflare routes traffic from a public hostname back down that connection to your local service. No inbound port needs to be open, and your local server keeps working with HTTP or HTTPS.

Quick tunnels

The fastest option needs no account or long setup. With a local dev server running, launch a quick tunnel:

cloudflared tunnel --url http://localhost:5173

This prints a random *.trycloudflare.com URL that proxies to your local server. It is ideal for a transient share or a quick test, but it is meant for testing only, has usage limits, and assigns a new random hostname each run.

Named tunnels

For a stable hostname that "just works" across sessions, create a named tunnel and publish it. The flow is:

1. Install and download cloudflared.
2. In the Cloudflare dashboard, create the tunnel and copy its install token.
3. Run cloudflared service install or the printed command so it connects persistently.
4. Add a public hostname route that maps a subdomain of your zone to a local service, for example https://dev.example.com to http://localhost:5173.

Because the tunnel keeps a persistent outbound connection, restarts are easier than with port forwarding, and you can reuse the same tunnel to expose several local services at once by adding more hostname routes.

A few tips that avoid common confusion:

• Confirm the local server binds to localhost or 127.0.0.1 so the tunnel's outbound connection reaches it.
• For HTTPS-only front ends, Cloudflare serves a valid edge certificate for the hostname without you running TLS locally.
• A webhook target on a quick-tunnel URL changes each time, so use a named tunnel when a vendor needs a fixed callback URL.
• Keep the tunnel running in its own window or as a service; closing it cuts the public route immediately.

Use this with the Worker request flow, then apply redirect rules and zone settings the same way you would for production, since the tunneled hostname behaves like a normal edge record.