Cloudflare Quick Tunnel Email Authentication: How to Protect Local Apps

A Cloudflare Quick Tunnel can now put an email check in front of your local development server with a single command-line option. The new --allowed-mail flag, available with cloudflared 2026.9.3, lets you share a temporary development URL with specific people or an entire email domain without requiring either side to have a Cloudflare account.

Cloudflare Quick Tunnel email authentication fixes the old sharing problem

Quick Tunnels are designed for a simple development workflow: run an application on your computer, expose its local port through cloudflared, and receive a temporary trycloudflare.com address that someone else can open. The drawback was equally simple: anyone who obtained that address could reach the application. That made Quick Tunnels convenient for demos and testing, but less comfortable when the local service contained unfinished features, private data, or development-only endpoints.

Cloudflare's new email authentication changes the access model without turning a Quick Tunnel into a conventional account-managed deployment. You specify the people who are allowed to enter when you start the tunnel. Visitors then verify control of an approved email address with a one-time PIN before Cloudflare allows the request to reach your local service. The developer still starts the tunnel from the terminal, and the visitor does not need to create a Cloudflare account.

Start with a normal Quick Tunnel before adding access control

The protected version uses the same basic command as an ordinary Quick Tunnel. First, make sure your local application is running and listening on a port. For example, a development server might be available on port 8080. Start the tunnel with the normal command and confirm that the generated temporary address can reach your application before adding authentication.

cloudflared tunnel --url http://localhost:8080

A Quick Tunnel creates a temporary hostname and does not require a Cloudflare account or a configured domain. The hostname is intended for testing and development rather than permanent production traffic. Cloudflare's documentation also lists a limit of 200 in-flight requests for each Quick Tunnel, so this mechanism should not be treated as a substitute for a production deployment or a permanent tunnel.

Add --allowed-mail to restrict who can open the tunnel

Once the unprotected tunnel works, restart it with the --allowed-mail option. The simplest form allows one specific email address. This is useful when you are sending a preview to one client, teammate, tester, or your own phone while keeping the development server closed to everyone else.

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

The result is different from a normal public Quick Tunnel. When Alice opens the generated address, she is asked for her email address and receives a one-time PIN. After entering the PIN, Cloudflare verifies that she controls the approved address. The authentication happens before the request reaches your local application, so your application does not need to implement a separate login page just for the preview.

Allow several developers without creating individual tunnels

You can add more than one permitted address by repeating the flag. This keeps the access list directly alongside the command used to start the development environment, which can be easier to understand than maintaining a separate configuration file for a short-lived demo.

cloudflared tunnel --url http://localhost:8080 \ --allowed-mail alice@example.com \ --allowed-mail bob@example.com

Cloudflare also accepts a comma-separated list. Both approaches express the same basic policy: the people who can successfully authenticate must match an address in the allowed list. Anyone who has the temporary URL but does not match the policy cannot reach the local application.

cloudflared tunnel --url http://localhost:8080 \ --allowed-mail 'alice@example.com,bob@example.com'

Use an email domain when the whole development team needs access

If the preview belongs to a team rather than a handful of named testers, you can allow an entire email domain. The wildcard form uses an asterisk before the domain name, so every address at the specified domain can authenticate.

cloudflared tunnel --url http://localhost:8080 \ --allowed-mail '*@example.com'

The quotation marks matter in shells that interpret wildcard characters themselves. Keeping the value quoted ensures that the wildcard is passed to cloudflared as part of the access rule rather than being expanded by the local shell. A domain-wide rule is convenient for an internal team, but it is broader than naming individual addresses, so it should be used only when everyone at that domain should be able to access the preview.

The email check proves identity, while cloudflared applies the guest list

The authentication flow separates two jobs that are easy to confuse. Cloudflare's email verification establishes that the visitor controls a particular email address. The cloudflared process running on your machine then compares that verified address with the rules you supplied when starting the Quick Tunnel. Authentication therefore answers “who controls this email?” while the local policy answers “is this email allowed into this tunnel?”

That distinction is useful because the local development application does not have to understand the authentication system. Cloudflare handles the browser-facing verification, while cloudflared enforces the list of permitted addresses. Cloudflare says authentication credentials are stripped before requests are forwarded to the local service, so the application does not receive the authentication material it would otherwise need to process.

Changing the allowed users means restarting the tunnel

The access list is tied to the Quick Tunnel process. If you need to add or remove someone, stop cloudflared and start a new Quick Tunnel with the revised --allowed-mail values. When the process stops, access to that temporary tunnel ends for everyone.

This behavior is appropriate for short-lived development environments but is worth remembering when a team expects a preview link to remain available all day. A change to the access list is not a dashboard operation that updates a persistent application. You change the command, restart the process, and receive a new temporary hostname. The new hostname also means any previously shared address should be replaced with the newly generated one.

Quick Tunnel email authentication works well for local demos

The feature fits particularly well when a developer needs someone outside the local machine to inspect work that is not ready for deployment. A client can open a preview from a phone, a designer can check a new interface, or another developer can test an endpoint without the application being publicly accessible to anyone who happens to discover the temporary URL.

It is also useful for development workflows driven by coding agents. An agent can start a local server and expose it through a Quick Tunnel, while an instruction can require the agent to include an approved email address whenever it creates the tunnel. Cloudflare's own example shows this pattern with an AGENTS.md instruction file, although developers should still inspect the command their automation actually executes rather than assuming an agent followed the instruction.

When you start a Quick Tunnel, always add --allowed-mail me@example.com.

For developers using Wrangler, Cloudflare also documents a Quick Tunnel command that accepts the same access-control option. That makes the feature available without manually invoking cloudflared when a project already uses the Wrangler command-line workflow.

npx wrangler tunnel quick-start http://localhost:8080 \ --allowed-mail alice@example.com

There are still reasons not to use a Quick Tunnel for production

Email authentication makes a Quick Tunnel safer to share, but it does not change what the product is designed for. Cloudflare documents Quick Tunnels as a testing and development feature, and the hostname changes each time a new Quick Tunnel is created. There is also no uptime guarantee, each tunnel supports up to 200 in-flight requests, and Server-Sent Events are not supported.

Those constraints matter when deciding whether a protected Quick Tunnel is enough. A temporary client preview can tolerate a changing hostname and a process that must remain running on a developer's machine. A production application normally needs a stable hostname, predictable availability, stronger identity-management controls, and infrastructure that does not disappear when a terminal process exits. For those cases, Cloudflare points developers toward a regular Cloudflare Tunnel rather than a Quick Tunnel.

Use the new flag when the problem is sharing, not deploying

The useful change is not that Quick Tunnels became a replacement for a production access system. They did not. The change is that a developer can now take a local application that would otherwise be exposed to anyone holding the temporary URL and put a small identity check in front of it without creating accounts, configuring a domain, or modifying the application itself.

For a one-person preview, start with one approved address. For a team demo, list the required addresses or use a domain rule when the broader access is intentional. If the project grows beyond a temporary preview, move to a persistent tunnel and a fuller access policy rather than stretching the Quick Tunnel beyond its purpose.