Cloudflare Tunnel: Securely Publish Internal Apps Without Opening Ports

Cloudflare Tunnel lets you publish internal web apps securely without opening inbound ports on your firewall. It’s a practical way to reduce external attack surface while keeping remote access simple.

Why use Cloudflare Tunnel

No direct NAT/port-forward to internal services
Traffic terminated and protected at Cloudflare edge
Easy pairing with Zero Trust Access policies

Prerequisites

Cloudflare-managed domain
Server hosting your internal app (Linux/Windows)
cloudflared installed

1) Authenticate cloudflared

cloudflared tunnel login

This links your connector to your Cloudflare account/zone.

2) Create a tunnel

cloudflared tunnel create internal-web

3) Route DNS hostname to tunnel

cloudflared tunnel route dns internal-web app.example.com

4) Configure ingress mapping

Create ~/.cloudflared/config.yml:

tunnel: internal-web
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - service: http_status:404

5) Run as persistent service

sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

6) Add access protection (recommended)

Create Access policy in Cloudflare Zero Trust
Restrict by user/group identity provider
Enforce MFA/session controls for sensitive apps

Troubleshooting quick checks

cloudflared tunnel list
journalctl -u cloudflared -f
Validate local app first: curl -I http://127.0.0.1:8080

This setup is reliable for home labs and production environments when combined with strict identity-based access policies.

Operational Checklist (Production-Safe)

Confirm prerequisites and permissions before changes.
Apply the change in staging or a low-risk window first.
Validate identity, network path, and policy scope before promoting changes to production.
Document rollback steps and owner responsibility.
Re-verify service health and security controls after completion.

Validation and Success Criteria

The target workflow completes without errors and without introducing service interruption.
Expected security/availability behavior is confirmed through logs and direct functional tests.
No unintended access, policy drift, or performance regression is observed after deployment.

Common Pitfalls to Avoid

Applying changes without confirming exact environment prerequisites.
Skipping post-change verification and relying only on command success output.
Not defining rollback steps before touching production assets.