On September 18, 2026, a link to Cloudflare’s Quick Tunnels page climbed to the top of Hacker News, collecting more than 800 points and 300 comments, according to Cloudflare’s own write-up. Two weeks later, on October 2, Cloudflare shipped email-gated access for the same feature: add an --allowed-mail flag and only the people you name can open your tunnel.
Quick Tunnels are not new. Cloudflare launched them on September 2, 2021, in a post by the summer intern who built them. What changed is how many developers, and how many coding agents, now reach for a one-command public URL. That makes it worth reading the documented limits calmly before you build a workflow on top of them.
This article covers what account-less tunnels do well, where the documentation says they stop, and which jobs suit a stable-subdomain tunnel.
Facts below were checked against Cloudflare’s documentation and changelog, and against each vendor’s own docs, on October 31, 2026. Disclosure: this article is published on the InstaTunnel blog, and InstaTunnel appears as one example in the stable-subdomain section.
What is a Cloudflare Quick Tunnel?
A Quick Tunnel is a temporary public URL on trycloudflare.com that forwards traffic to a service on your machine. You need no Cloudflare account and no domain. The whole setup is one command:
cloudflared tunnel --url http://localhost:8080
cloudflared prints a random hostname. Visitors reach it over HTTPS, the request travels down an outbound connection your machine opened to Cloudflare, and your local server answers. Your router never accepts an inbound connection. Cloudflare’s docs state the trade-off plainly: anyone with the URL can reach your local service, and the URL stops working when you stop the cloudflared process.
Cloudflare’s 2021 launch post explains the mechanics. A Cloudflare Worker generates the random subdomain, a DNS record is created for it, and a scheduled job deletes tunnels that have been disconnected for more than five minutes.
Why account-less tunnels caught on
Zero signup friction. Before Quick Tunnels, the 2021 post says, trying Cloudflare Tunnel meant creating an account, adding a website, changing nameservers and waiting for DNS propagation. For a developer showing a half-finished build to a client, skipping all of that is the appeal.
Agents can run it unattended. A coding agent cannot fill in a signup form, but it can run a shell command. Cloudflare’s announcement describes agents using Quick Tunnels to show previews, expose a local MCP server, or reach a machine at home. Adding --output json makes each log line a JSON object. Flavio Copes tested this and found the URL is still embedded inside the message field, so a program still has to pattern-match it out of the line.
Real HTTPS from localhost. Browsers limit APIs such as the camera, geolocation and service workers to secure contexts. Your phone treats a plain-HTTP LAN address as insecure, while a tunnel URL is a real HTTPS origin.
The downside was always the same: anyone holding the link could open it. TechSpot notes that security firms have documented criminals abusing free, anonymous tunnels to stage malware, and that ngrok’s founder said in the Hacker News thread that his company dropped anonymous tunnels years ago because the abuse wasn’t worth it. Account-less is a trade, not a free lunch.
What --allowed-mail actually adds
Starting with cloudflared 2026.9.3, you can restrict a Quick Tunnel by email address:
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com
Alice opens the URL, enters her email address, receives a one-time PIN, and then reaches your app. Per Cloudflare’s documentation you can:
- repeat the flag for multiple addresses,
- pass a comma-separated list in quotes, or
- allow a whole domain with a quoted wildcard such as
'*@example.com'.
Visitors do not need a Cloudflare account, and Cloudflare says email protection is free like Quick Tunnels themselves. If you omit the flag, nothing changes and the tunnel stays public. To change who has access, stop cloudflared and start a new tunnel. Access ends for everyone when the process exits.
If you build on Workers, Cloudflare says the same flags work through npx wrangler tunnel quick-start, and that Wrangler removes --allowed-mail values from its debug logs.
How the design works
Cloudflare splits the problem in two. Cloudflare Access verifies that a visitor controls an email address. A small stateless broker on Workers turns that into a short-lived, signed assertion. Then cloudflared, on your machine, decides whether that address is on your list.
Cloudflare says it rejected two simpler designs. One was putting an Access application in front of every Quick Tunnel hostname, which would mean provisioning applications and policies for a huge number of short-lived tunnels with no account to own them. The other was building the whole login flow from scratch.
The consequence of the chosen design is that your guest list never leaves your machine. Cloudflare learns that a tunnel requires email authentication, not who you invited. A protected tunnel also never falls back to public mode: if the service does not confirm the authentication mode, cloudflared refuses to start. Sessions last up to four hours (less if the visitor’s Access sign-in expires sooner) or until you stop the process.
Cloudflare’s post adds a footnote: the feature was shipped by two interns.
Making it the default for agents
For agent workflows, Cloudflare suggests one line in AGENTS.md telling the agent to always add --allowed-mail with your address. The caveat is worth repeating: agents do not always follow instructions, so check what actually ran. cloudflared prints whether email authentication is active and how many rules it holds, without printing the addresses.
Where Quick Tunnels stop: the documented limits
Cloudflare’s Quick Tunnels documentation (last updated September 30, 2026) lists these limitations:
| Limit | What the docs say | What it means in practice |
|---|---|---|
| Uptime | No uptime guarantee | Fine for a demo, wrong for anything users depend on |
| Concurrency | Up to 200 in-flight requests; additional requests get a 429
|
A busy test page or a load test can trip it |
| Streaming | No Server-Sent Events (SSE) support | Live-updating pages built on SSE will not behave |
| Hostname | Changes each time you create a Quick Tunnel | Every restart means a new URL |
| Email gate | Requires an interactive browser session; no non-interactive clients | Automated callers cannot pass the PIN |
The same page labels Quick Tunnels as for testing and development, and points to a named Cloudflare Tunnel for stable hostnames and production traffic.
The 200 in-flight request cap
“In flight” means requests being proxied at the same moment, not per second. A typical dev preview never gets near 200; a crawler or load test can. The failure is explicit: requests beyond the cap return an HTTP 429.
No SSE
Cloudflare’s Sandbox SDK documentation explains the mechanism: the trycloudflare.com edge buffers text/event-stream responses, so events never reach the client in real time. The same page says WebSockets work normally and that named tunnels support SSE. This matters because many chat interfaces and dashboards stream over SSE.
Hands-on testing by Flavio Copes on cloudflared 2026.9.1 adds nuance absent from the docs. GET responses were held until they finished, POST responses streamed as written, and WebSockets worked both ways. That would explain why a POST-based LLM API can appear to work while a browser EventSource (always GET) does not. This is one person’s observation on one version, not a guarantee, so test your own stream.
No uptime guarantee, and the URL is disposable
Cloudflare’s docs promise no uptime, and the hostname is regenerated on every start. Any system that stores your URL needs updating each time.
The email gate and automated callers
This is the limit most likely to surprise people. Cloudflare’s changelog lists a “webhook receiver” among the things you might share with specific people. The Quick Tunnels documentation, however, says email authentication requires an interactive browser and does not support non-interactive clients. A webhook sender cannot type an address and read a PIN, so by the documented restriction it should be blocked. That is an inference from the docs, so test it before relying on it. The email gate is built for people reviewing a demo, and it does that job well.
Practical tips for demos
These come from Flavio Copes’s hands-on guide and are observations, not documented guarantees.
- The DNS gap. He measured 3 to 33 seconds between the URL appearing and its DNS record resolving. Scripts that fetch the URL immediately can fail, and he reports that early failed lookups can be cached by resolvers for a long time.
-
Dev servers reject unfamiliar hosts. Vite refuses requests whose
Hostheader it does not recognize. Either add.trycloudflare.comtoserver.allowedHostsor start the tunnel with--http-host-header localhost:<port>. -
An existing config file can interfere. His guide says Quick Tunnels do not work if a
config.ymlexists in~/.cloudflared, as it might from an earlier named tunnel. Rename it temporarily. - Cloudflare sits in the traffic path. He notes Cloudflare terminates the visitor’s TLS. Tailscale’s docs, by contrast, say Funnel relay servers cannot decrypt traffic. Either way, keep real customer data out of demo tunnels.
Where a stable-subdomain tunnel fits
The limits above point to a clear dividing line. Quick Tunnels are excellent when the job is short, the audience is small and nothing stores the URL. A stable-subdomain tunnel fits when any of these are true:
- A third party stores your URL. Webhook dashboards, OAuth redirect URI allowlists and embed allowlists all expect an address that does not change.
- The audience is automated. Webhook senders and CI jobs cannot complete an interactive login.
- The session outlives a laptop sleep. You want the same address tomorrow morning.
- You need streaming or more concurrency than a Quick Tunnel allows.
Here is how the main options compare, using each vendor’s own documentation.
| Option | Stable URL? | What you need | Notes from the docs |
|---|---|---|---|
| Cloudflare Quick Tunnel | No, random each start | Nothing | Limits listed above |
| Cloudflare named tunnel | Yes, a hostname you choose | Free account plus a domain on Cloudflare DNS | Cloudflare recommends this for stable hostnames and production traffic; SSE supported per the Sandbox docs |
| ngrok free plan | Yes, one assigned dev domain that persists across restarts; you cannot choose the name | ngrok account | Up to 3 online endpoints, 1 GB/month transfer out, 20,000 requests/month; an interstitial page is shown in front of HTML browser traffic |
| Tailscale Funnel | Yes, on your *.ts.net name |
Tailscale installed, MagicDNS, HTTPS and Funnel enabled | Beta; public ports limited to 443, 8443 and 10000; bandwidth limits are non-configurable |
| InstaTunnel | Yes, via --subdomain
|
The npm CLI | README documents --password, --auth (basic auth) and custom domains on Pro/Business plans; the README says the deployment is currently single-region (US) |
A few clarifications keep this table honest.
Named Cloudflare tunnels use the same cloudflared binary, at the cost of owning a domain on Cloudflare DNS. If you already do, this is the natural upgrade.
ngrok’s free plan keeps a persistent dev domain, but the name is assigned, not chosen. Its docs say the interstitial warning page appears in front of all HTML browser traffic on the free tier, with a cookie suppressing it for 7 days after a visitor clicks through. API and programmatic traffic is not affected, and a documented ngrok-skip-browser-warning request header bypasses it. Custom and reserved domains require a paid plan, and free endpoints have no timeout.
Tailscale Funnel suits existing Tailscale users. The fixed ports and ts.net naming constrain webhook providers and branded demos.
InstaTunnel documents instatunnel 3000 --subdomain myapp and a protected review-link example using --auth. Its README also describes an MCP streaming transport (v2) listed under its Pro and Business features. I could not verify its free-tier session limits from the README, so check its pricing page before relying on any free-tier claim, as with any vendor.
A practical decision checklist
Ask these questions in order and stop at the first “yes”:
- Will anything outside your machine remember this URL? (webhook dashboard, OAuth allowlist, a teammate’s bookmark) Use a stable-subdomain tunnel.
- Does the visitor have to be a script? Skip the email gate. Use a stable tunnel with token or basic authentication that a machine can send, and verify webhook signatures in your handler.
- Does your app stream over SSE or expect more than 200 concurrent requests? Use a named tunnel or another provider.
-
Is it a one-off review by a few humans? A Quick Tunnel with
--allowed-mailis hard to beat. It is fast, free, and the guest list stays local. - Is it production? Not a Quick Tunnel. Cloudflare says so itself.
Whichever you pick: tunnel only the port you mean to share, stop the tunnel when you finish, and keep real customer data out, since a hosted provider sits in the traffic path.
Frequently asked questions
Are Cloudflare Quick Tunnels free?
Yes. They need no account or domain, and Cloudflare says email protection is free too. They carry no uptime guarantee and are meant for testing and development.
How do I restrict a Quick Tunnel to certain people?
Use cloudflared 2026.9.3 or later and add --allowed-mail with an address, a comma-separated list, or a quoted wildcard like '*@example.com'. Visitors confirm with a one-time PIN and need no Cloudflare account.
Why does my Quick Tunnel return a 429 error?
Quick Tunnels allow up to 200 in-flight requests, and additional requests get an HTTP 429. If you hit it regularly, move to a named tunnel or another provider.
Do Quick Tunnels support Server-Sent Events?
No. Cloudflare’s docs say so, and its Sandbox docs list SSE as supported on named tunnels.
Can I keep the same URL after a restart?
Not with a Quick Tunnel, because the hostname changes each time. Use a named Cloudflare Tunnel on your own domain, or a service with reserved subdomains.
Why is Vite blocking my tunnel URL?
Vite rejects hosts it does not recognize. Add .trycloudflare.com to server.allowedHosts, or start the tunnel with --http-host-header set to your local host and port.
Conclusion
Account-less tunnels get the first five minutes right: no signup, one command, real HTTPS, and now a guest list that stays on your machine. They stop where the documentation says: no uptime guarantee, 200 in-flight requests, no SSE, a hostname that changes on every start, and an email gate machines cannot pass.
Use a Quick Tunnel for the demo. When a webhook provider, an allowlist or a teammate’s bookmark needs the address to stay put, switch to a stable-subdomain tunnel and stop pasting new URLs.
Sources
- Cloudflare Docs: Quick Tunnels
- Cloudflare Changelog: Protect Quick Tunnels with email authentication (2026-10-02)
- Cloudflare Blog: Protected Quick Tunnels
- Cloudflare Blog: Quick Tunnels: Anytime, Anywhere (2021)
- Cloudflare Sandbox SDK: Tunnels
- TechSpot: This one-command trick can put your localhost on the internet
- Flavio Copes: The complete guide to Cloudflare Quick Tunnels
- ngrok Docs: Free plan limits
- Tailscale Docs: Funnel
- InstaTunnel README on npm (v1.1.23)
Originally published at https://instatunnel.my/blog/after-the-quick-tunnels-moment-what-account-less-tunnels-get-right-and-where-they-stop
Top comments (0)