Cloudflare Tunnel vs publishing directly — when each fits

Cloudflare Tunnel (formerly Argo Tunnel) is a free way to expose a service on your VPS to the public without opening any ports on the VPS itself — an outbound persistent connection from the VPS to Cloudflare's network carries the traffic. The tradeoff is real, both ways. This article explains when it's the right call and when publishing directly is simpler.

How Cloudflare Tunnel works

1. You run cloudflared as a daemon on the VPS.
2. It establishes outbound TLS connections to Cloudflare's edge.
3. Cloudflare publishes a DNS record for your service pointing at their edge.
4. Public requests hit Cloudflare → tunneled inbound to your VPS → response sent back through the tunnel.

No inbound ports needed on the VPS. The VPS firewall can drop everything inbound (even 80/443) and the service still works.

When Cloudflare Tunnel is the right choice

• You want DDoS protection without paying for it. Cloudflare's free tier absorbs L3/L4 attacks at the edge; only legitimate traffic reaches your VPS.
• You're behind CGNAT or otherwise can't open ports. (Doesn't apply to LYLIX VPSes — you always have a real public IP — but useful background if you're tunneling to a home lab too.)
• You want geographically distributed caching. Cloudflare's CDN caches static content at their edge globally. Page-load times for distant users drop dramatically.
• You want their security features — WAF, bot management, rate-limiting at the edge — without integrating them yourself.
• You're sharing a single VPS hosting multiple sites, and Cloudflare's free SSL terminations are easier to manage than coordinating Let's Encrypt for many domains.

When direct is better

• Latency-sensitive workloads. Every request goes Cloudflare → your VPS → Cloudflare. For interactive applications (especially WebSockets, real-time games, video conferencing), the extra hop adds meaningful latency.
• Mail and other non-HTTP protocols. Cloudflare Tunnel is HTTP-only by default. SMTP, SSH, IMAP, SIP — none work via standard tunnel config.
• Compliance-sensitive workloads. Cloudflare can see your unencrypted traffic at the edge. For regulated workloads, MITM by a third party may be a non-starter.
• You don't want to depend on a third party's availability. Cloudflare has had real outages; when their edge is down, your tunneled service is down too. Direct publishing depends only on your VPS being up.
• Bulk file transfer / large-asset serving. Cloudflare's free tier has bandwidth limits (the soft "no excessive non-HTML content" clause). Self-hosting through the tunnel for video or large downloads can get throttled.

The setup, in case you decide to use it

# Install cloudflared (per their docs)
# Debian/Ubuntu:
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
dpkg -i cloudflared.deb

# Authenticate (opens browser to your Cloudflare account)
cloudflared tunnel login

# Create the tunnel
cloudflared tunnel create my-app

# Configure /etc/cloudflared/config.yml
tunnel: <tunnel-id-from-above>
credentials-file: /root/.cloudflared/<tunnel-id>.json
ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404         # fallback

# Route DNS
cloudflared tunnel route dns my-app app.example.com

# Run as a service
cloudflared service install
systemctl status cloudflared

App is now reachable at https://app.example.com with Cloudflare's cert; your VPS has no inbound ports open.

The hybrid approach

Most operators end up with a mix: latency-sensitive paths direct (SSH, mail), public website + APIs through Cloudflare. Run nginx/Caddy on your VPS as normal for direct services, run cloudflared in parallel for the ones you want behind their edge.

If you choose to publish through Cloudflare's standard "Orange Cloud" mode (where Cloudflare proxies but you still publish your real IP), enforce that real traffic only comes from Cloudflare's IPs:

# nginx — only accept traffic from Cloudflare's IP ranges
# (https://www.cloudflare.com/ips/ has the current list)
allow 173.245.48.0/20;
# ... all Cloudflare ranges ...
deny all;

Without this, attackers who learn your real IP can bypass Cloudflare entirely. With Cloudflare Tunnel (the topic of this article), this is moot — there's no inbound port at all to bypass.