Cloudflare Tunnel

Overview¶

Cloudflare Tunnel is a secure, outbound-only connection between your server and the cloudflare edge. A cloudflared daemon runs on your machine and establishes a persistent outbound tunnel, allowing local services to be exposed through public hostnames without opening inbound firewall ports. It replaces traditional reverse proxies and port-forwarding in self-hosted setups, especially on an Oracle ARM VPS running docker.

How it works¶

The tunnel is configured in the Cloudflare dashboard under Networking → Tunnels. Once a tunnel is created, you add Public Hostname entries that map a subdomain (e.g. chrome.benhoweb.com) to a local service using the HTTP type. Instead of typing localhost:3000, you use the container name and the internal port, for example http://browserless:3000.

This only works when the service container and the cloudflared container share the same Docker bridge network. In the typical setup, all web-facing containers join an external network named cf_network:

networks:
  cf_network:
    external: true

A strict security rule applies: containers on cf_network must never publish ports to the host (no ports: - "8080:80"). This eliminates the direct external attack surface entirely — Cloudflare Tunnel becomes the only entry point.

Security hardening¶

Publicly exposing services through a tunnel means you should add Cloudflare Access application rules in front of sensitive hostnames. For example, a self-hosted vaultwarden instance at pass.benhoweb.com can require Windows Hello / passkey verification before the request reaches the password manager. Browserless, which can execute arbitrary JavaScript, should also be protected with MFA to prevent it being used as a jump box.

Some applications require their own authentication on top of Cloudflare Access. When browserless/chrome has a TOKEN environment variable set, opening the URL without the token returns Unauthorized. You must visit https://chrome.benhoweb.com/?token=YOUR_TOKEN to access the Playground. Internal services like n8n can call http://browserless:3000/content?token=YOUR_TOKEN directly over cf_network, bypassing the public internet and reducing latency.

Secrets and automation¶

Tunnel tokens, Cloudflare API tokens, and zone IDs are sensitive values that should not live in plain .env files. Use infisical as a central secrets manager — it stores CLOUDFLARE_TUNNEL_TOKEN, CF_API_TOKEN, and other credentials with versioning, audit logs, and RBAC. During deployment, secrets are injected at container startup (e.g. infisical run -- docker compose up), keeping git history clean.

For static sites and games, github-actions can automate deployments to cloudflare-pages using cloudflare/wrangler-action@v3. Secrets such as CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID are stored as GitHub Secrets and passed to the action.

Use cases¶

Exposing self-hosted web apps on Oracle ARM without public ports
Serving LiteLLM Proxy endpoints for AI tools
Providing secure access to internal automation platforms like n8n
Protecting Vaultwarden or other sensitive services behind biometric Cloudflare Access
Deploying browser games to cloudflare-pages with automatic builds
Keeping high-privilege admin panels hidden behind a VPN (e.g. wireguard) instead of a public tunnel

Notes¶

In the current Cloudflare dashboard, the path is Networking → Tunnels. Older setups sometimes created a second tunnel-network, but the recommended pattern is to unify all web services onto the same cf_network and let cloudflared route traffic internally. Tools like litellm and n8n benefit from using internal container names, avoiding public round-trips entirely.