Production sites behind Cloudflare Tunnel. Cloud-bill complexity not required.

This site — www.nerdheadz.com — runs on a single box at 192.168.1.210. There is no public IP exposed. There is no firewall port open to inbound traffic. The origin is unreachable from the public internet by design. What you reach through your browser is Cloudflare's edge, which forwards requests to a tunnel daemon on that local box. The tunnel routes six services from one machine:

- www.nerdheadz.com → port 3000 (this Next.js app) - estimate.nerdheadz.com → port 5175 (the AI estimator) - estimation-api.nerdheadz.com → port 8000 (estimator backend) - upwork.nerdheadz.com → port 5176 - upwork-api.nerdheadz.com → port 8001 - content-api.nerdheadz.com → port 8002

Catch-all unknown subdomains return 404. Total infra cost on the cloud side: $0. The pattern works for any team that wants origin protection without managing a separate firewall layer or pinning a static cloud IP — see how this slots into our web development engagement shape.

Tunnel is the right pattern for most production work, but not all of it. Real cases where we choose differently:

- High-throughput APIs that bill on bandwidth. Cloudflare's pricing curve makes egregious egress expensive. A 50TB/mo media API is cheaper to front through a CDN with origin pull and dedicated bandwidth quotas. - Compliance regimes that require origin IP whitelisting. Some financial integrations enumerate allowed source IPs. Edge-fronted traffic looks like Cloudflare to the upstream, so the whitelist breaks. Dedicated origin IP wins. - Long-running WebSockets at scale. Tunnel handles WebSocket fine technically, but config drift between Free tier and Workers Unlimited gets fiddly past ten thousand concurrent connections. - Sub-100ms request paths where every hop matters. Edge-to-origin adds a hop. For most sites this is invisible; for HFT-adjacent work, it is a deal-breaker.

This is the section competitors will not write — it sounds like negative selling. It is actually credibility. If your build looks like one of these, we will say so on the call instead of selling you Cloudflare Tunnel anyway.

A working pattern, not a feature catalog. Concrete usage on production sites we run:

- Tunnel — primary pattern for origin protection. Single config file at /etc/cloudflared/config.yml routes subdomains to local ports. - Cache — s-maxage=3600 for hub pages, s-maxage=14400 for detail pages, with manual purge on deploy via the API. Cache hit rate runs 90%+ on this site. - Transform Rules — header injection without origin code change. Live example on this zone: X-Robots-Tag: noindex, nofollow set on *-api.nerdheadz.com subdomains, so Search Console does not pollute on internal API endpoints. - Bulk Redirects — apex nerdheadz.com → www.nerdheadz.com. Browser-cached, edge-resolved, zero origin hop. - R2 — used for nightly MongoDB backups and media offload. S3-compatible API plus zero egress fees inside Cloudflare's network. - Workers — sparingly. Origin compute as default; Workers only when a response is fully derivable from the request and global latency matters.

Pair this with maintenance and support to keep the operational layer alive after launch — origin observability, runbooks for tunnel outages, and the boring on-call rotation.

The third row is what www.nerdheadz.com runs on. The trade-off is operational: hardware on your premises means power redundancy is on you, not on the cloud provider. For a development agency that is a feature, not a bug — outage drills happen on real hardware in real conditions. Deployment topology questions belong early in scoping; bring them to our custom software development entry point, or look at how the pattern slots in with our Next.js work.