Security and access control

Opening your localhost to the world requires responsibility. ResolveLabs Tunnel intercepts traffic on our Edge servers before it reaches your machine, so you control exactly who gets in.

Secure by default

• Encrypted transport. The CLI connects out to our Edge over TLS 1.3. No inbound ports are opened on your network.
• HTTPS public URLs. Every HTTP tunnel gets a valid certificate (TLS 1.2 or newer).
• Port isolation. The tunnel is strict: it only has permission to reach the port you specify. The rest of your file system and databases stay isolated and invisible.
• Safe terminal. Anything a visitor controls (URL paths, headers) is sanitized before it is printed, so nobody can inject escape sequences into your terminal.

What TLS does and doesn't cover

CLI  <== TLS 1.3 ==>  Edge  <== TLS 1.2+ (valid certificate) ==>  visitor                      (the Edge terminates TLS to route and authenticate)

The connection between the CLI and the Edge is encrypted, and so is the visitor's connection to the Edge. But the Edge terminates TLS: it has to read the request to route it by hostname, apply Basic Auth and the IP allowlist, and build the inspector log. So this is not end-to-end encryption: treat the Edge as a trusted party, and the last hop (CLI to your app) is plain HTTP on your own machine. The Edge does not store request bodies.

Password protection (Basic Auth)

Keep curious people and bots out by adding an authentication layer with a single command:

rl-tunnel http 3000 --auth "admin:password123"

Visitors see a browser login prompt. The credentials are checked at the Edge, so unauthenticated requests never reach your machine. The tunnel's own Authorization header is not passed to your app.

IP allowlist

Limit access to your office, VPN or a client's ranges. Repeat the flag for several entries (single IPs or CIDR ranges):

# Only these IPs/ranges can reach the tunnelrl-tunnel http 3000 --allow-ip 203.0.113.0/24 --allow-ip 198.51.100.7

The Edge uses the real connection address. A visitor cannot get around the list by sending a fake X-Forwarded-For header.

Inspector and privacy

The inspector shows each request to you only. Bodies are capped at 32 KiB and WebSocket/streaming responses are listed with headers only. Use --no-body so that bodies are never captured, and see Traffic inspector for what is stored on your machine.

Limits that protect everyone

• Every tunnel requires a logged-in account, and new connections per minute are limited per IP.
• Accounts have a cap on simultaneous tunnels, reserved subdomains and tokens.
• Tokens are stored hashed. Revoking one closes its open tunnels within about a minute.

Checklist before exposing an app

• Is there private data? Add --auth or --allow-ip.
• Does the traffic carry secrets (payments, health data)? Use --no-body.
• Is it a database? Use strong credentials and close the tunnel when finished.
• Is it a dev server with debug endpoints? Turn them off or restrict access.
• Close the tunnel (Ctrl+C) when you stop using it.