Ngrok vs. Hookdeck CLI: The Pure Webhook Specialist

Current comparison
Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.
Open the InstaTunnel ngrok alternative guideQuick answer
ngrok vs Hookdeck CLI: The Ultimate Tool for Webhook Testing: quick answer
If free tunnel limits interrupt your workflow, compare session length, stable URLs, concurrent tunnels, and paid-plan pricing before choosing a localhost tunnel tool.
What free tunnel limits should developers check first?
Check session duration, URL stability, concurrent tunnels, custom subdomains, bandwidth or request limits, and whether webhook callbacks survive restarts.
How does InstaTunnel handle longer development sessions?
InstaTunnel Free is designed around 24-hour sessions, with Pro available for higher limits and MCP endpoint tunnel workflows.
Modern application design leans heavily into event-driven architecture. Third-party APIs like Stripe, Shopify, GitHub, and Twilio communicate critical data back to internal systems via asynchronous HTTP POST requests — webhooks. Historically, local development environments have been isolated from the public internet by firewalls, routers, and NAT. To bypass this and receive real webhook payloads on http://localhost, engineering teams have traditionally reached for ngrok. As the industry-standard tunneling tool, ngrok creates a public URL that mirrors traffic directly to a local development port.
But ngrok treats webhooks as just another payload in a generic HTTP stream. As applications shift toward decentralized microservices, noisy event networks, and stricter reliability requirements, general-purpose tunnels start to show their limits.
Hookdeck CLI takes a different approach. Instead of acting as a transparent network pipe, it’s a dedicated event gateway built specifically for webhooks that happens to handle local tunneling as one of its features. This guide compares the two at the architectural, operational, and workflow level — and corrects several claims that circulate in comparison content but don’t hold up against the tools’ current documentation.
Architectural Paradigms: Open Tunnels vs. Subscription Streams
How ngrok Operates: The Open Infrastructure Tunnel
When you run ngrok http 3000, the ngrok agent establishes a long-lived outbound connection to ngrok’s cloud infrastructure. ngrok assigns a public URL and forwards every packet sent to that endpoint over the connection to your local port.
[Webhook Source] ---> [ngrok Cloud Edge] ===(Encapsulated Tunnel)===> [ngrok Agent] ---> [Local Server:3000]
Under this model:
- The layer: It functions as a Layer 4 (TCP/TLS) or Layer 7 (HTTP) reverse proxy, and — as of 2026 — a broader “universal gateway” with its own YAML-based Traffic Policy layer for routing, rewriting, and access control at the edge.
- The scope: The tunnel exposes whatever is listening on that local port. If your framework serves ten routes, all ten are reachable through the public endpoint unless you scope the tunnel or write a Traffic Policy rule to restrict it.
- The state: Without any policy configured, it behaves as a stateless stream — traffic is pushed through in real time as it arrives.
How Hookdeck CLI Operates: The Webhook Subscription Stream
Hookdeck functions as an asynchronous event broker that sits between the third-party provider and your local machine, rather than a raw network bypass.
+---> [Dev Machine A: Port 4000]
[Webhook Source] ---> [Hookdeck Event Gateway (Queue / Broker)] ===(CLI Stream)===> |---> [Dev Machine B: Port 4000]
+---> [Dev Machine C: Port 5000]
Running hookdeck listen 4000 <source-name> doesn’t just pipe a port — it creates three abstractions inside your Hookdeck project:
- Source: A persistent tracking endpoint mapped to an upstream platform (e.g.,
stripe-webhooks). The CLI assigns a permanent URL underhkdk.eventsthat stays the same across restarts. - Destination: A definition pointing at your local target (e.g.,
http://localhost:4000). - Connection: The binding between Source and Destination — a stateful, isolated subscription stream, not a raw pipe.
When a webhook hits the Hookdeck edge, it’s acknowledged immediately and queued, then delivered to whichever local CLI session is subscribed. If your local server crashes or is paused on a breakpoint, the event stays queued rather than being dropped — Hookdeck’s own documentation describes this as an at-least-once delivery guarantee backed by durable queueing.
One correction worth making up front: using the CLI’s forwarding features does require a free Hookdeck account (hookdeck login) — it isn’t account-free the way some comparison pages suggest. What it is free of, per Hookdeck’s own npm and GitHub documentation, is a credit card and any cap on event URLs for local development: “unlimited free and permanent event URLs” for the CLI use case specifically.
Technical Comparison Matrix
| Capability | ngrok | Hookdeck CLI |
|---|---|---|
| Core architecture | General-purpose L4/L7 reverse proxy, now expanding into a broader API/AI gateway | Purpose-built webhook event gateway |
| Tunnel state | Stateless forwarding by default | Stateful (ingested, queued, and managed) |
| URL stability (free tier) | One auto-assigned dev domain per account that persists across restarts, but cannot be customized; TCP addresses are randomly assigned unless you verify a card | Permanent Source URL per project; requires a free account (no card) |
| Traffic filtering | Edge-level via Traffic Policy (a separate YAML rule language, billed per Traffic Policy Unit) — not webhook-payload-aware out of the box | Native, granular filters on header, body, path, or query via CLI flags or the dashboard |
| Fan-out / routing | Primarily 1:1; multi-destination fan-out is possible via a wildcard endpoint’s forward-internal Traffic Policy action, but requires manual configuration |
Native 1:many fan-out — one Source can feed multiple Connections/Destinations |
| Team isolation | 1 team member on Free and Hobbyist; unlimited members (3 included) only on the Pay-as-you-go tier | Each developer runs their own CLI session against shared Sources with session-level filtering — no seat requirement |
| Debugging interface | Local web dashboard at localhost:4040 with request replay |
Full terminal UI (TUI) plus the Hookdeck web console |
| Retry/replay | Manual replay via the local dashboard | Keyboard-driven instant retry (r) in the CLI, plus configurable automatic retry rules |
| AI agent integration | None in the CLI itself (ngrok does offer separate MCP-related tooling for connecting other MCP servers through its gateway) | Built-in MCP server (hookdeck gateway mcp) exposing 11 tools |
Core Differentiators
1. Granular Event Filtering vs. Firehose Exposure
A single Stripe payment can trigger payment_intent.created, customer.updated, charge.succeeded, and invoice.created in quick succession. If you’re only debugging charge.succeeded, a plain tunnel forwards all of it — every request hits your local server, consuming CPU and cluttering logs, unless you’ve separately written an edge policy to filter it.
Hookdeck’s CLI supports filtering directly as flags on listen, matching the real reference syntax:
hookdeck listen 4000 stripe-webhooks --filter-body '{"type": "charge.succeeded"}'
The CLI also supports --filter-headers, --filter-query, and --filter-path for matching on other parts of the request. Events that don’t match are filtered out at the gateway — they never reach your terminal or local server, which keeps your debugging session focused on the payloads under test.
(Note: --path is a different flag — it sets where events are forwarded on your local server, e.g. --path /webhooks/stripe. It’s not a filter, and conflating the two is a mistake worth avoiding if you’re scripting this.)
2. Multi-Target Fan-Out for Microservice Architectures
Consider an e-commerce checkout: a single completed-order webhook might need to reach a fulfillment service, an analytics pipeline, and a notification system running on three different local ports. With a plain tunnel, you’d need three separate public URLs registered with the provider — or a hand-rolled reverse-proxy script to duplicate and reroute the payload — unless the provider supports registering multiple endpoints natively.
+---> Destination 1: http://localhost:5001 (Fulfillment)
[Single Stripe Source URL] --->|---> Destination 2: http://localhost:5002 (Analytics)
+---> Destination 3: http://localhost:5003 (Notifications)
Hookdeck treats this as a native pattern: one Source can map to multiple Connections, each pointing at a different Destination, filtered or transformed independently.
3. Native Team Workflows
When multiple developers share a staging Stripe or Shopify account, they typically compete for control of a single registered webhook URL — if Developer A points it at their personal tunnel, Developer B’s session breaks.
Hookdeck’s documentation describes a specific fix for this: each developer runs their own hookdeck listen session against the same shared Source, using session-level filters (for example, routing by a query parameter or header tagged to that developer) so each person only receives the events relevant to their own work, without reconfiguring the upstream provider.
Debugging: Terminal UI vs. Web Dashboard
ngrok provides a local dashboard at http://127.0.0.1:4040 — a dual-pane view of inbound requests with full headers and body, plus a manual “Replay” button that resends a captured request to your local endpoint. It’s a solid interface, but it lives in a browser tab, separate from your terminal.
Hookdeck CLI runs an interactive full-screen terminal UI by default (--output interactive), with compact and quiet as alternative startup modes for lower-verbosity logging — these are flags you launch with, not toggles you switch mid-session. A real session looks roughly like this:
●── HOOKDECK CLI ──● Listening on 1 source • 1 connection • [i] Collapse
Shopify Source │ Requests to → https://hkdk.events/src_...
└─ Forwards to → http://localhost:3000/webhooks/shopify/orders
Events • [↑↓] Navigate
─────────────────────────────────────────────────────────
> 2026-07-10 14:42:55 [200] POST /webhooks/shopify/orders (34ms)
✓ Last event succeeded | [r] Retry • [o] Open in dashboard • [d] Show data
The documented keyboard shortcuts are: ↑/↓ (or vim-style j/k) to navigate, r to instantly retry the selected event against your local server, d to view full request/response detail inline, o to open the event in the Hookdeck web console for deeper tracing, and i to collapse or expand the connection header. Retrying with r replays the exact same payload without re-triggering the event from the provider — useful for iterating on handler code without waiting on Stripe or Shopify to resend anything.
AI-Driven Workflows via MCP
Hookdeck CLI v2 (released March 2026) added a built-in MCP server, started with:
hookdeck gateway mcp
You don’t run this directly — your MCP client (Claude Desktop, Cursor, etc.) launches it as a subprocess over stdio:
{
"mcpServers": {
"hookdeck": {
"command": "hookdeck",
"args": ["gateway", "mcp"]
}
}
}
Per Hookdeck’s own release notes, the server exposes 11 tools: projects, connections, sources, destinations, transformations, requests, events, attempts, issues, metrics, and a help catch-all. These are described as “mostly read and inspect tools — the things an agent needs to answer ‘what’s failing and why?’ without opening the Dashboard.” The connections tool is the one exception with write access: it supports pausing and unpausing a connection. If you haven’t authenticated yet, a hookdeck_login tool appears automatically and removes itself once you’re logged in.
A representative workflow from Hookdeck’s own writeup: an agent pulls overall metrics, spots an elevated failure rate, narrows it to a specific connection (say, shopify-orders → fulfillment-service), inspects a failed event and its delivery attempts, and traces the root cause to a destination service that only handles one event subtype and is rejecting the rest with 422s — at which point the fix (a filter rule) is a CLI operation the agent hands off to you rather than applying itself.
(For context: ngrok has its own, separate AI-adjacent feature set — it markets itself as a way to expose or connect MCP servers through its gateway — but that’s a different capability from Hookdeck CLI having its own MCP server that lets an agent introspect webhook delivery health.)
Pricing at a Glance
This is where a lot of comparison content online is out of date, so here’s what each vendor’s own pricing page states as of mid-2026.
ngrok (per ngrok.com/pricing):
| Tier | Price | Key limits |
|---|---|---|
| Free | $0 | 3 online endpoints, 1GB data transfer, 20k HTTP requests/mo, interstitial warning page on HTTP endpoints, 1 team member |
| Hobbyist | $8/mo billed annually ($10 billed monthly) | 3 online endpoints, 5GB data included, 100k requests included, no interstitial page, ngrok-branded domains |
| Pay-as-you-go | $20/mo base + usage | Unlimited endpoints, bring-your-own domain, unlimited team members (3 included), SSO/RBAC available as an add-on |
Worth flagging directly: a number of third-party ngrok comparison articles state that the free tier enforces a hard 2-hour session timeout. ngrok’s own documentation states the opposite — free-tier endpoints do not have a timeout and can run indefinitely as a background service. The real free-tier constraints are the 1GB/month bandwidth ceiling, the 20k request cap, and the forced interstitial page (removable with a request header or any paid plan).
Hookdeck (per hookdeck.com/pricing, for the production Event Gateway — separate from the CLI’s free local-dev usage):
| Tier | Price | Key limits |
|---|---|---|
| Developer (Free) | $0 | 10,000 events/month, 3-day retention, 1 user, no card required |
| Team | $39/mo base | Pay-as-you-go beyond base (roughly $0.33 per 100k additional events), unlimited users, 7-day retention |
| Growth | $499/mo | Uptime/latency SLAs, SSO/SAML/SCIM, Datadog metrics export, 30-day retention |
Hookdeck’s homepage states a 99.999% uptime target for the underlying Event Gateway infrastructure — that’s a vendor claim, not an independently audited figure, but it’s stated directly on their own site rather than inferred from a third party.
Production Readiness: From Local Dev to Enterprise Edge
A common gap with any local tunnel is what happens when you move to production. ngrok is designed primarily for development and ad hoc exposure; production use requires layering on your own retry logic, rate limiting, and signature verification, or paying for ngrok’s production-tier gateway features to get some of that at the edge.
Hookdeck’s pitch is that the same Source/Connection/Destination model carries over unchanged — you just point the Destination at your production URL instead of the CLI. According to Hookdeck’s own retry documentation, automatic retries are capped at 50 attempts per event, and separate Hookdeck guidance describes retry windows stretching up to roughly a week as a configurable ceiling — notably more aggressive than what Stripe or Shopify do natively on their own webhook retry schedules. Failed events that exhaust retries are grouped into “Issues” (added alongside request-level issue detection in the March 2026 CLI release) rather than silently dropped, with Slack/PagerDuty alerting and bulk-retry once the underlying problem is fixed.
Final Assessment
Choose ngrok when you need to expose a local server quickly for a demo, are testing general HTTP/TCP/TLS traffic that isn’t specifically webhook-shaped, or want the most widely documented tunneling tool that shows up in nearly every provider’s integration guide.
Choose Hookdeck CLI when you’re working with noisy or high-volume webhook streams that need filtering to stay debuggable, need a single event to fan out to multiple local services, have a team sharing one staging webhook source and tripping over each other’s tunnels, or want the local development workflow to carry over to production without re-architecting retry and observability logic from scratch.
Changelog
Corrections and additions made to the original draft, checked against each vendor’s current documentation (July 2026):
- ngrok free-tier URL stability: Original draft claimed free-tier URLs are “ephemeral, changes every time the agent restarts.” ngrok’s own pricing/limits docs state the free tier gets one auto-assigned dev domain that persists across restarts (though it can’t be customized). Corrected the comparison matrix accordingly; noted that TCP addresses specifically are randomly assigned unless a card is verified.
- ngrok free-tier session timeout: Removed an implied 2-hour session timeout claim that circulates in third-party comparison content but is explicitly contradicted by ngrok’s own documentation (“the free tier does NOT have timeouts on endpoints”).
- ngrok pricing tiers: Replaced outdated third-party figures (“Personal $8/mo, Pro $20/mo, Enterprise $39/mo”) with the tier names and prices from ngrok’s own current pricing page (Free, Hobbyist at $8/mo annual or $10/mo monthly, Pay-as-you-go at $20/mo base).
- Hookdeck “no account needed” claim: Corrected — the CLI requires a free Hookdeck account (
hookdeck login) even though local-dev event URLs are unlimited and free. - Hookdeck CLI filter command syntax: The original draft’s example (
hookdeck listen 4000 stripe-webhooks --path /webhooks/stripe) misused--path, which sets the local forwarding path, not a filter. Replaced with the CLI’s actual filter flags (--filter-body,--filter-headers,--filter-query,--filter-path) per the current CLI reference. - Hookdeck TUI keybindings: Corrected the illustrative keybinding diagram to match the documented shortcuts (
rretry,dshow data,oopen in dashboard,icollapse/expand header) and clarified that compact/quiet modes are launch-time flags, not in-session toggles. - ngrok traffic filtering: Softened the original “None” claim — ngrok has a YAML-based Traffic Policy layer that can filter or rewrite at the edge, though it’s a separate policy language rather than webhook-payload-aware filtering out of the box.
- ngrok fan-out: Noted that ngrok’s wildcard endpoints with a
forward-internalTraffic Policy action can technically achieve multi-destination routing, rather than stating fan-out is impossible on ngrok. - Hookdeck MCP tool descriptions: Tightened against Hookdeck’s own v2 release notes — confirmed 11 tools, added that
connectionsis the one tool with write access (pause/unpause), and that ahookdeck_logintool appears automatically pre-authentication. - Added: A sourced pricing section for both tools, since pricing structures for both changed materially in the past several months and weren’t in the original draft.
- Removed: Unverifiable or vendor-marketing-only figures (e.g., specific latency/throughput numbers sourced only from third-party aggregators rather than the vendor’s own site).
Sources
- ngrok Pricing — https://ngrok.com/pricing
- ngrok Pricing and Limits docs — https://ngrok.com/docs/pricing-limits
- ngrok Free Plan Limits — https://ngrok.com/docs/pricing-limits/free-plan-limits
- Hookdeck CLI reference — https://hookdeck.com/docs/cli
- Hookdeck CLI GitHub — https://github.com/hookdeck/hookdeck-cli
- Hookdeck CLI v2 (MCP) announcement — https://hookdeck.com/blog/hookdeck-cli-v2
- Hookdeck March 2026 changelog — https://hookdeck.com/blog/hookdeck-review-march-2026
- Hookdeck Retries docs — https://hookdeck.com/docs/retries
- Hookdeck Pricing — https://hookdeck.com/pricing
- Hookdeck localhost testing guide — https://hookdeck.com/docs/use-cases/test-debug-localhost
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.