localtunnel alternatives

localtunnel earned its popularity honestly: npx localtunnel --port 3000 and you have a public URL, free, no account. But if you're searching for an alternative, you've probably hit one of the walls that the free public server has grown over the years:

• The password interstitial. To fight phishing, the public server shows first-time visitors a "friendly reminder" page that demands the tunnel password — which is your machine's public IP. Browser demos survive that; many programmatic senders don't. A third-party service POSTing a webhook or callback at your tunnel can't click through an interstitial or attach the bypass-tunnel-reminder header, so the request dies at the wall.
• Reliability. It's a free volunteer-run server; downtime, connection resets, and "incorrect password" glitches are a fixture of the issue tracker.
• Rotating URLs. Subdomains are random per session unless yours happens to be free — so every restart can mean re-configuring the webhook provider.
• Node required. The client is an npm package — friction in a Go/Python/Rust project or a slim container.
• It's still an open port to your laptop. Anyone who learns the URL can reach your dev server directly while the tunnel is up.

If the traffic is webhooks: skip the tunnel entirely

A tunnel solves "expose my whole dev server to the internet." If what you actually need is "get webhook deliveries into localhost," you can flip the model: give the provider a stable capture URL, and pull deliveries down yourself.

$ curl -s https://hookden.pages.dev/cli -o hookden && chmod +x hookden
$ ./hookden new                              # → stable /h/… URL, paste into the provider once
$ ./hookden relay YOUR_BIN http://localhost:3000

• No interstitial, ever. The capture URL answers every sender with your configured response (200 by default). Nothing between the provider and the capture.
• The URL never rotates. Configure GitHub/Stripe/Shopify once; the bin outlives laptop sleeps, network changes, and restarts. Deliveries that arrive while the relay isn't running persist and re-deliver when you start it.
• Byte-identical re-delivery — method, sub-path, query, headers, exact body bytes — so HMAC signatures (X-Hub-Signature-256 and friends) still verify in your local handler. Full walkthrough.
• No Node, no daemon, no open port. The CLI is a POSIX shell script needing only curl and sed; it polls outbound, so nothing on your machine is reachable from the internet.
• Everything is also inspectable in the web dashboard: headers, JSON pretty-printed, signature ✓/✗ badges, diff, replay, HAR/JSON export. Free, no paid tier.

Trade-offs, honestly: this only works for webhook-style traffic — it won't serve a whole website or WebSocket app the way a tunnel does. Relay polls, so deliveries land within a couple of seconds rather than instantly, and bodies over 100 KB are truncated on relay (the CLI warns you).

If you really need a tunnel

• cloudflared (cloudflared tunnel --url http://localhost:3000) — robust infrastructure, free quick tunnels, no interstitial. Trade-offs: random trycloudflare.com URL each run; a stable named tunnel needs an account and a domain. Full tunnel comparison.
• localhost.run / serveo — SSH-based, zero install. Same class of trade-offs as localtunnel: random URLs, small-operator reliability.
• ngrok — polished and stable, but the free tier's limits, auth requirements, and URL rotation are usually what sent people to localtunnel in the first place.
• Self-host the localtunnel server — the server is open source; running your own on a VPS removes the interstitial and the shared-server flakiness, at the cost of operating a public-facing service (and now you have a VPS with a public URL — you could just deploy there).

Quick chooser

• Webhooks/callbacks into local code, URL that never changes → Hookden relay.
• Demo a whole web app to a human → cloudflared quick tunnel.
• Traffic can't touch third-party infra → self-host a tunnel server on your own VPS.

← All guides · Docs · Hookden vs webhook.site