Skip to main content
Docs

Quickpass: Invite-Only Tunnels Without Changing Your App

Every localhost tunnel tool gives you a public URL. Almost none let you choose who can open it without bolting auth onto your app, paying for enterprise add-ons, or standing up a VPN.

Quickpass is Asyx’s answer: passwordless, invite-only access enforced at the relay edge. You add one CLI flag. Visitors verify by email, their device is remembered, and your code stays untouched.

Only on Asyx

ngrok and Cloudflare Tunnel can gate traffic, but they expect you to wire OAuth, Access policies, or basic auth into your stack. Quickpass is built for “share this localhost link with these people” — the same workflow as an open tunnel, with a membership check first.

Why developers use Quickpass

ProblemOpen tunnelQuickpass
Client preview under NDAAnyone with the linkOnly emails in your security group
AI-built demo on your laptopPublic by defaultInvite reviewers; block the internet
Internal dashboard on a tunnel hostnameLeaks if URL spreadsGroup membership required every session
File folder over HTTPSWorld-readableSame URL, invite-only guests
Webhook testing✅ (no browser)Usually skip Quickpass

How it compares to alternatives

ApproachApp changes?Guest experienceOps burden
QuickpassNoneMagic link + remembered deviceCreate group, add emails, one CLI flag
Basic auth in your appYesUsername/passwordYou maintain credentials
VPNNone on appInstall VPN clientHeavy for a 10-minute demo
ngrok OAuth / Cloudflare AccessOften yes / policy UIIdP-dependentEnterprise-style setup
“Security through obscurity”NoneHope the URL doesn’t leakFragile

Quickpass is not a replacement for app login when every user needs an account inside your product. It is the right layer when the tunnel itself should not be public.

How it works (high level)

Visitor → https://you.tunnel.asyx.ai
       → Relay checks Quickpass cookie / session
       → Not enrolled? Redirect to /qp/enroll (magic link)
       → Email in your security group? Set cookie, forward to localhost
       → Not in group? /qp/denied (signed in but not authorized)
  1. You create a security group in the Quickpass console and add member emails.
  2. You open a tunnel with --secgroup <name>:
asyx tunnel --http --port 3000 --secgroup reviewers
  1. Visitors hit your tunnel URL. Unauthenticated browsers go to enroll (/qp/enroll).
  2. After passwordless email sign-in and group check, traffic reaches your app. Return visits reuse remembered devices — no password to type, no VPN.

Enforcement happens before your process sees the request. Your framework’s auth, cookies, and routes are unchanged.

Setup in three steps

1. Create a security group

In Console → Quickpass:

  • Create a group (e.g. reviewers, client-acme, friends).
  • Add member email addresses (the same inbox they’ll use to enroll).

Groups are the unit of access: one --secgroup per tunnel invocation.

2. Open a protected tunnel

asyx tunnel --http --port 3000 --secgroup reviewers

If you change the group name or member list, stop and reopen the tunnel so policy updates apply to that session.

3. Share the tunnel URL

Send https://yourname.tunnel.asyx.ai to members. First visit walks them through Quickpass enrollment; later visits are frictionless on the same device.

Common workflows

Protect a client preview

npm run dev   # localhost:3000
asyx tunnel --http --port 3000 --secgroup client-acme

Share the tunnel URL in email. Only addresses in client-acme get through — not everyone on the internet.

Private demo after Cursor or Claude builds a UI

asyx tunnel --http --port 5173 --secgroup demo-reviewers

See AI Agents and Cursor + Asyx.

Invite-only file share

python3 -m http.server 8000 --directory ~/share
asyx tunnel --http --port 8000 --secgroup friends

See Share Files.

Safer local LLM or admin UI

For anything beyond a throwaway demo, gate the tunnel:

asyx tunnel --http --port 11434 --secgroup llm-lab

See Local LLM / Ollama.

What guests see

First visit (not enrolled)
Redirect to enrollment → enter email → magic link → if the email is in your group, they land on your app.

Return visit (device remembered)
Straight through — no password.

Signed in but not in the group
A denied page: they proved identity but are not on the list. Add their email in the console and ask them to retry.

Webhooks and API clients
Quickpass is browser-session oriented. Stripe/GitHub webhooks hitting your tunnel typically use an open HTTP tunnel (no --secgroup). See Webhooks from Localhost.

Operator checklist

  • Group created in console with correct member emails
  • Tunnel started with --secgroup <exact-name>
  • Members know to use the same email you added
  • After membership changes, tunnel restarted
  • Sensitive apps never use a bare asyx tunnel without Quickpass unless intentional

Architecture notes (brief)

  • Edge enforcement — Unauthorized requests never reach your localhost listener.
  • Passwordless — Email magic link, not shared passwords in Slack.
  • Device memory — Trusted devices skip re-enrollment; you can reason about “this laptop” without managing passwords.
  • Per-tunnel policy — The --secgroup on the CLI binds that tunnel lease to a group for its lifetime.

For a full security comparison with ngrok and Cloudflare, see Security Comparison and vs ngrok & Cloudflare.

FAQ

Does Quickpass work with TCP or Minecraft?
Today Quickpass applies to HTTP tunnels. TCP/UDP game servers and databases use different access patterns.

Is this MFA?
It is passwordless verification plus device memory — not TOTP authenticator MFA.

Can one tunnel use multiple groups?
One --secgroup per tunnel. Run separate tunnels for separate audiences.

Do I need to change my Express / Next / Flask app?
No. Keep your app as-is; Quickpass sits in front on the tunnel hostname.

What if someone forwards the URL?
They still must pass Quickpass enrollment and be in the group. An open URL is not enough.

How is this different from ngrok’s basic auth?
No shared password to rotate. Members prove email identity; devices are remembered per guest.

Related guides