Free ngrok alternatives for webhook testing

ngrok is great until you hit the free-tier walls: an account + authtoken before the first request, monthly quotas (1 GB of transfer and 20,000 HTTP requests on today's free plan), a browser-warning interstitial that trips automated callers, and a single auto-assigned dev domain. If all you need is webhooks reaching your dev machine, you have options. Here's an honest rundown — including where each one beats the others. (Debugging a specific error page instead? See ERR_NGROK_108 / 3200 / 121 / 6024 explained. Want the broader survey including Tailscale Funnel and VS Code port forwarding? See how to expose localhost, honestly compared.)

1. cloudflared (Cloudflare Tunnel)

$ cloudflared tunnel --url http://localhost:3000

Good: free, no account needed for quick tunnels, solid infrastructure.
Trade-offs: you get a random trycloudflare.com URL that changes every run — so you're back to re-configuring the webhook provider each time. A stable named tunnel requires an account and a domain. It's a full tunnel daemon, which some corporate networks and CI environments block.

2. localtunnel / serveo / localhost.run (SSH-based)

$ ssh -R 80:localhost:3000 nokey@localhost.run

Good: nothing to install (SSH is everywhere), no account.
Trade-offs: random URLs per session, variable reliability (these are mostly volunteer/small services and go down or rate-limit), and some inject an interstitial page that breaks non-browser webhook senders — localtunnel's password page is the classic case (details and alternatives).

3. VS Code / dev-container port forwarding

Good: built into tools you already run.
Trade-offs: URLs require auth by default (webhook senders can't log in), tied to your editor session, not scriptable in CI.

4. The no-tunnel approach: capture + relay

All of the above solve "expose my laptop to the internet." But for webhooks you can flip the problem: give the provider a stable capture URL, and pull the captures down to localhost yourself.

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

Every webhook that arrives is re-delivered to your local server with the original method, sub-path, query string, headers, and a byte-identical body — so HMAC signatures (GitHub's X-Hub-Signature-256, Stripe's, Shopify's) still verify in your real handler code.

Good:

• The URL is stable — restart the relay, reboot, switch networks; the provider config never changes. Signed-in bins keep the same URL for as long as you want (free custom slugs like /h/my-stripe-dev make it memorable).
• It's outbound-only polling with curl — no daemon, no open ports, works behind NAT, corporate proxies, and locked-down CI runners where tunnels are blocked.
• You get inspection for free: every delivery is also in a dashboard with headers, pretty-printed body, signature ✓/✗ badges, replay, and diff — so when your local handler misbehaves you can see exactly what was sent.
• No account needed to try it; no paywall on the relay.

Trade-offs, honestly: it's polling, so delivery to localhost lags a couple of seconds behind the original webhook — fine for development, not for exposing a production service. It only speaks HTTP (no raw TCP/TLS tunneling, no custom domains pointing at your laptop). If you need a browser to reach your local app from the internet, you still want a real tunnel; if you need webhooks, this is simpler and stabler.

Quick chooser

• Demo a local web app to a human → cloudflared.
• One-off quick test, nothing installed → localhost.run via SSH.
• Webhook development, stable URL, signature-safe, works everywhere → capture + relay (below).

← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site