Cloudflare Tunnel Is Now Fully Free — What Zero-Open-Ports Ingress Means for Your Self-Hosted PaaS

Cloudflare quietly removed the last reason to think of Tunnel as a rate-limited product. What used to be Argo Tunnel — a bandwidth-metered feature you paid for by the gigabyte — is now completely free, with unmetered bandwidth and no cap on how many tunnels you run. Point a domain's nameservers at Cloudflare, run one daemon, and you can expose a service to the internet without opening a single inbound port, buying a static IP, or touching your router's firewall rules.

That's a real capability shift for anyone running a self-hosted PaaS, not just a pricing footnote. But the free tier isn't the only thing changing: on October 5, 2026, Cloudflare is retiring the CIDR-encoded route endpoints in its Zero Trust Networks API and dropping the connections field from tunnel list/get responses. If you've scripted anything against Tunnel's API — which any platform automating tenant ingress would have — that date is a hard deadline, not a suggestion.

What Actually Changed​

Two separate things happened, and it's worth being precise about both because they land on different timelines.

The free tier. Cloudflare Tunnel — the successor to what was originally branded Argo Tunnel — now ships with unmetered bandwidth and no limit on tunnel count. There's no per-GB charge, no tunnel quota gating you into a paid plan, and no feature-flagged "basic tier" cliff waiting a few hundred requests in. The only genuinely free-tier limitation that survives is on the access-control side: Cloudflare Zero Trust Access — the layer that gates who can reach a tunneled service, separate from the tunnel itself — stays free only up to 50 users, after which Cloudflare One bills per-user. The tunnel transport itself has no such ceiling.

The API deprecation. Starting October 5, 2026, Cloudflare is removing the CIDR-encoded route endpoints from the Zero Trust Networks API, and tunnel list/get responses will no longer include the connections field. Concretely:

• Any code calling the old CIDR-encoded route endpoints (URL-encoding a CIDR range directly into the request path) needs to move to the standard route_id-based endpoints, which already exist today and work identically for every other resource in the Zero Trust Networks API.
• Any code reading tunnel connection state via the connections field on tunnel list/get calls needs a different source for that data after October 5 — the field is gone, not deprecated-but-present.
• If you manage routes with cloudflared tunnel route ip add | delete, you need to be on a current cloudflared version before the cutover, since older CLI builds assume the endpoints being removed.

None of this touches the free/unmetered pricing change — it's a routine API cleanup Cloudflare is running in parallel. But it's the part that actually breaks automation if you ignore it, so it's the part worth putting on a calendar.

How the Tunnel Actually Works​

The mechanism is what makes "zero open ports" true rather than marketing language. cloudflared — a small daemon you run next to the service you want to expose — opens an outbound-only connection to Cloudflare's edge and keeps it alive (over QUIC/HTTP3 by default now, which recovers faster on flaky networks than the older HTTP/2 transport). Inbound requests from the internet hit Cloudflare's edge first, then ride that already-established outbound connection back to your origin.

Because the connection direction is origin-to-Cloudflare, not Cloudflare-to-origin, your firewall doesn't need an inbound allow rule at all — the standard default-deny-inbound, allow-outbound firewall posture already supports it with zero changes. There's no public IP to route to, no port-forwarding rule on a home router or cloud security group, and nothing for a port scanner to find, because there's nothing listening for inbound connections in the first place.

What This Buys a Self-Hosted PaaS's Tenants​

For a platform like Bex.co — where a tenant pushes a git repo and gets a running HTTPS service on machines the platform owns — the default ingress path is the platform's own ACME/DNS-01 pipeline: the platform terminates TLS on its own edge, issues certificates for the tenant's custom domain, and the tenant points DNS at an IP or CNAME the platform controls. That's the right default because it keeps the whole request path — DNS, TLS, routing — inside the platform's own infrastructure, with no third party in the loop.

Cloudflare Tunnel is a different, complementary option, and it's a genuinely good one for a specific tenant shape: someone who doesn't want to manage DNS pointed at the platform at all, doesn't care about a fully custom domain, or is running something they'd rather not expose via a stable public IP even behind the platform's own proxy — an internal dashboard, a staging environment, a demo they want to kill in an hour. For that tenant, Tunnel means:

• No DNS changes on the platform's side — the tunnel's hostname routing lives entirely in Cloudflare's config, not the platform's DNS records.
• No inbound port or IP exposure from the node running the workload, on top of whatever isolation the platform already provides.
• TLS handled entirely by Cloudflare's edge, with zero certificate lifecycle for that specific route to manage anywhere.

That's a real, free capability a platform can point a subset of tenants at — not a fallback, a legitimate first choice for the "I just want a URL, don't make me think about DNS" use case.

What You Give Up by Routing Through It​

The tradeoff is control, and it's worth being blunt about where it bites.

TLS terminates at Cloudflare, not at the platform. Cloudflare's edge decrypts the request, then re-encrypts (or doesn't) on the hop to your origin depending on your Cloudflare SSL mode. That means Cloudflare sees plaintext traffic the platform's own DNS-01 pipeline never would — the platform's own ACME automation keeps the TLS termination point inside infrastructure it operates end to end, with no intermediary that can read the traffic in transit.

Cloudflare's uptime becomes your uptime. A tunnel makes the tunneled service reachable through Cloudflare's edge, full stop. If Cloudflare has an outage, every tunneled service goes dark, even for traffic that would otherwise never have touched Cloudflare's network at all — including local-network access to a service, if it's routed through the same tunnel. A platform's own ACME/DNS-01 ingress has exactly one added dependency in its critical path (the DNS provider that answers the DNS-01 challenge, and only during certificate issuance/renewal, not on every request) — nothing sits between every live request and the origin the way Cloudflare's edge does for a tunneled one.

DNS lock-in. Tunnel requires the domain's nameservers to be Cloudflare's, not just a CNAME pointed there. Once a domain's authoritative DNS lives at Cloudflare and routing config accumulates around it, moving that domain to a different provider later is a migration project, not a DNS record edit — a cost that doesn't exist for a domain whose DNS-01 records point at infrastructure the platform already owns.

Here's the side-by-side for the same tenant custom-domain use case:

Neither column is strictly better — they're solving for different tenants. A platform that only offers one of the two is leaving a real use case unserved: either forcing every tenant through a DNS setup they didn't want, or forcing every tenant through a third party's edge they didn't ask to trust.

The October 5, 2026 Migration Checklist​

If a platform (or a tenant's own automation) has any code touching the Tunnel API directly — not just the cloudflared daemon, but anything calling the Zero Trust Networks API to manage routes or read tunnel state — here's what breaks and what replaces it:

1. CIDR-encoded route endpoints → route_id-based endpoints. If you're calling an endpoint that takes a URL-encoded CIDR range in the path, switch to the equivalent route_id-based endpoint. These aren't new; they already exist and work the same way every other resource in the API is addressed.
2. connections field removal. If anything reads the connections field from a tunnel list or get response to check tunnel health or connection count, that field disappears on October 5. Find a different source for that data before the cutover — don't wait for the field to silently start returning empty.
3. cloudflared version. If routes are managed via cloudflared tunnel route ip add | delete, confirm you're on a current release before October 5. Older builds assume the endpoints being retired.

None of this is a breaking change to the tunnel transport itself — existing tunnels keep working, existing cloudflared daemons keep connecting. It's specifically the management API surface that's narrowing, and it only bites automation that was calling the old endpoints directly.

Where Each Approach Actually Belongs​

The two aren't an either/or a platform has to pick once. A Cluster API-managed fleet can run its own ACME/DNS-01 pipeline as the default for tenants who bring a custom domain and want it fully under their own control — and offer Cloudflare Tunnel as an opt-in route for tenants who'd rather skip DNS configuration entirely, side by side, per tenant, on the same fleet. That's the "supplement" reading of Cloudflare's free-tier change: not a replacement for platform-owned ingress, but a second, zero-config on-ramp a platform can offer without operating any of it itself.

What changed this month is that offering it costs nothing and scales without a bandwidth bill — which makes "supplement" a much easier default to say yes to than it was when Tunnel metered every gigabyte.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with ACME/DNS-01 TLS automated for every tenant custom domain. Star the repo on GitHub or deploy your first app today.

Sources​

• Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026 — Cloudflare Changelog.
• Cloudflare Tunnel — Cloudflare Zero Trust docs.
• Connect with cloudflared — Cloudflare Learning Paths.