localtunnel

Last reviewed Aug 26, 2026 · 789 words

npx localtunnel --port 3000 hands you a public HTTPS URL for a local dev server in about 5 seconds, and that is the entire product. The catch is where the URL comes from: the shared localtunnel.me server, which is free, volunteer-run, and flaky enough that I stopped trusting it for anything a colleague or a webhook provider needs to reach twice. The server side is MIT-licensed and small, so the real question for a self-hoster is whether a wildcard DNS record and a 128 MB Node process are worth owning the URL. For a dev-only webhook endpoint on a domain you already have, yes. For anything longer-lived, no, and I'll name what to run instead.

The public server is why people leave

The client has been around since 2015 and has 22,456 stars because the ergonomics are perfect: no signup, no token, one flag, and --subdomain hooks if you want a stable name. Reliability is the trade. Tunnels drop mid-session, subdomains get reused, and the shared endpoint now shows an interstitial on first visit asking for a tunnel password (your public IP) before it passes traffic through, which defeats the purpose when the "visitor" is Stripe or GitHub trying to deliver a webhook. Treat the public server as a demo of the protocol, not as infrastructure.

Self-hosting the server is 90% DNS and firewall

The server is one Node package, localtunnel/server on GitHub, and it needs a machine with a public IP plus a wildcard record, because every tunnel becomes a subdomain:

tunnel.example.com.    A  203.0.113.10
*.tunnel.example.com.  A  203.0.113.10

On the VPS:

git clone https://github.com/localtunnel/server.git && cd server
npm install
bin/server --port 80 --domain tunnel.example.com

The repo ships a Dockerfile if you'd rather docker build it. Then from your laptop, lt --port 3000 --host https://tunnel.example.com --subdomain hooks and the endpoint is https://hooks.tunnel.example.com.

The part that catches people: the client's HTTP request to the server only negotiates the tunnel. The actual traffic runs over a raw TCP connection to a random high port the server hands out per client. A VPS firewall that opens only 22, 80, and 443 will silently break every tunnel. Either open the ephemeral port range or don't firewall the box beyond SSH, and accept that this is uglier than it should be.

TLS needs a wildcard certificate in front

The server doesn't terminate TLS itself. Put Caddy in front with a DNS-challenge wildcard certificate for *.tunnel.example.com and proxy to the Node process on port 80. Caddy passes WebSocket upgrades through by default, which the tunnel relies on. Without the wildcard cert every new subdomain would need its own certificate, and Let's Encrypt rate limits will find you within a week.

There is no auth, and that's not fixable

localtunnel's security model is "the subdomain is a secret". Anyone who guesses or reuses it reaches whatever you exposed, and there's no access list, no basic auth, no request log or replay inspector (ngrok's actual killer feature). The self-hosted server at least means the operator of the relay is you. For a dev server that only exists during a debugging session, this is fine. For a service you leave up overnight, it isn't, and no amount of subdomain entropy changes that.

The better long-term servers

If you're standing up a VPS anyway, frp does the same job with a shared auth token, fixed ports, TCP and UDP forwarding, and a 10 MB Go binary, and its config is 6 lines. For giving teammates access to a service on your LAN rather than the public, a VPN is the safer shape; the remote access comparison walks through the trade-offs. For a full ngrok-style replacement with per-share auth and a dashboard, zrok is the closest match, and the ngrok alternatives page covers the rest.

What I'd do

Keep the localtunnel client installed for throwaway demos where a dropped tunnel costs nothing; npx it against the public server and move on. For webhook development against a domain I own, I'd spend the afternoon on frp rather than the localtunnel server: same self-hosted-relay model, but with a token, predictable ports, and no wildcard-DNS or ephemeral-port surprises. localtunnel earned its stars by being the easiest client ever written; the server was never the point, and self-hosting it is the one case where the simplest tool is not the simplest setup.