A production tunnel, not just a cloudflared install
A basic tunnel can be online in minutes. The production work starts after that: deciding which hostnames should exist, keeping the origin private, mapping the right services, applying identity rules, handling credentials safely and making failures observable.
The result is a documented path from Cloudflare to your origin with clear ownership and rollback steps. Your existing application can stay on the same server while public traffic moves behind Cloudflare in a controlled cutover.
- ▸ Named tunnel deployment with Docker Compose or a hardened systemd service
- ▸ DNS and multi-hostname routing for websites, APIs and internal tools
- ▸ Origin service mapping, TLS mode and trusted proxy configuration
- ▸ Optional Cloudflare Access policies for identity-gated routes
- ▸ Replica design, health checks, logs and restart behavior
- ▸ Configuration notes, credential inventory and handover checklist
Where Cloudflare Tunnel is a strong fit
Tunnel is most useful when an origin should be reachable without accepting unsolicited inbound traffic. It works well for a production website behind a private firewall, an API that should only be reached through Cloudflare, or an internal tool that needs identity-aware access.
It can also simplify migrations when a server has no stable public IP, sits behind carrier-grade NAT, or should not expose SSH and administration ports to the internet.
- ▸ Websites and APIs running on a VPS, home lab or private cloud
- ▸ SSH, dashboards, admin panels and internal developer tools
- ▸ Multiple subdomains routed to separate local services
- ▸ Origins behind NAT where port forwarding is unavailable or undesirable
- ▸ Replacing a public reverse proxy with an outbound-only connector
Identity, WAF and origin protection belong in the same design
A tunnel hides the origin from direct inbound connections, but it does not decide who should reach every application. Public websites, staff-only tools and machine APIs need different policies. NexaForge separates those paths and adds Cloudflare Access, WAF rules or service tokens where they make sense.
The origin is checked as well: listening interfaces, firewall rules, trusted proxy headers and application redirects can all undermine an otherwise correct tunnel configuration.
- ▸ Public routes remain public while sensitive routes require identity
- ▸ SSH and internal applications can be protected without publishing their ports
- ▸ API routes can use service credentials instead of interactive login
- ▸ Origin firewall rules are tightened after the Cloudflare path is verified
High availability and troubleshooting that survives handover
A second connector can run as a replica of the same tunnel so one host or process failure does not remove the only path. For higher-risk systems, the design includes connector placement, restart policies and a tested failure scenario rather than a second container that has never been exercised.
Logs are kept useful and minimal. The handover shows how to distinguish DNS, edge, connector and origin failures, which shortens recovery when the tunnel is no longer the newest part of the system.
- ▸ Replica placement on separate hosts where the origin architecture supports it
- ▸ Service restart, boot persistence and controlled cloudflared upgrades
- ▸ Connector health and application-level checks
- ▸ Troubleshooting runbook for 502, 1033, DNS and Access policy failures
Scope and pricing
A single-server production setup is usually $149–299. A Tunnel + Zero Trust engagement is usually $399–699. These are discovery ranges, not a fixed quote; the final scope depends on the number of origins, hostnames, access policies, migration constraints and availability requirements.
Cloudflare plan charges, third-party identity provider fees and application changes are not included unless the quote lists them. Existing incidents or compromised servers are assessed separately before migration.
- ▸ Included: configuration, deployment, verification, documentation and handover
- ▸ Optional: Zero Trust policies, WAF rules, replica design and monitoring
- ▸ Not assumed: application rewrites, domain transfer or 24/7 managed operations