Webhooks on localhost: how n8n flows receive events behind a tunnel

Q: Is the public URL stable enough to register with a service?

A named redock.xyz subdomain stays consistent, which is what you want when registering webhooks. Random QuickShare links are better for quick one-off tests. Details are in the sharing docs.

A webhook needs a public URL to deliver to, and localhost isn’t public — that’s the whole problem with testing webhook-driven n8n flows on your Mac. ReDock solves it by opening a Cloudflare tunnel that gives your local n8n instance a stable public address. Stripe, GitHub, Typeform, or any service that posts events can then reach a workflow running on your laptop, with real HTTPS and no port forwarding.

Why localhost can’t receive webhooks

When a service sends a webhook, it makes an HTTP request from its servers to a URL you gave it. That URL has to resolve on the public internet and accept an inbound connection. Your laptop sits behind NAT and a router — outbound requests work, but nothing on the internet can dial back in. So a webhook configured to hit http://localhost:5678/webhook/... simply never arrives.

The classic workarounds are a paid tunneling service, manual router port-forwarding (fragile and a security risk), or deploying n8n to a server just to test. All of them slow down the loop between “wire the webhook” and “see it fire.”

How ReDock’s tunnel closes the gap

ReDock is a free (alpha) native macOS app that runs n8n as a built-in stack. When you turn on sharing for a site, ReDock opens a Cloudflare tunnel and hands you a public URL that forwards to your local instance:

A stable public address. Either a random QuickShare link or a named redock.xyz subdomain. You paste that URL into the sending service’s webhook settings.
Real HTTPS end to end. The tunnel terminates TLS, so services that require https:// (most of them) are satisfied, and your local instance still sees a clean request.
No router changes. Nothing is exposed on your home network. The tunnel is an outbound connection from your Mac to Cloudflare’s edge; events ride back down it.

The mechanics live in the sharing docs, and the one-click n8n setup is covered in n8n on your Mac, one click.

Wiring a webhook flow, step by step

The pattern is the same for any provider:

Add a Webhook trigger node in n8n. It gives you a path like /webhook/abc123.
Build the public URL. Combine your ReDock tunnel address with that path.
Register it with the service. Paste the URL into Stripe’s webhook settings, GitHub’s repo webhooks, or your form tool’s integration panel.
Send a test event. Most services have a “send test” button. Watch it land in n8n’s execution log.
Build the rest of the flow downstream of the trigger — parse the payload, act on it, respond.

Because you see the execution log live, debugging a mis-shaped payload is immediate — no redeploy, no waiting.

Development reachability vs. production

Be clear-eyed about what this is for. A tunnel to your laptop is right for development, personal automation, and demos. Your Mac has to be awake and ReDock running for events to arrive. That’s a fine trade for building and testing.

For a webhook endpoint that must be up 24/7, you’d eventually move the workflow to an always-on server. The good news: it’s the same n8n, so the workflow exports as JSON and runs unchanged. ReDock also does one-click Cloudflare deploys for the sites it hosts — see what MCP unlocks and the automation pillar n8n on your Mac for where this fits. To have an agent help assemble the flow, see n8n + Claude via MCP.

FAQ

Do I need to configure my router or firewall?

No. The Cloudflare tunnel is an outbound connection from your Mac. Nothing is opened on your home network, and you don’t touch port forwarding.

Is the public URL stable enough to register with a service?

A named redock.xyz subdomain stays consistent, which is what you want when registering webhooks. Random QuickShare links are better for quick one-off tests. Details are in the sharing docs.

What if a webhook arrives while my Mac is asleep?

It won’t be received — the tunnel needs your Mac awake and ReDock running. For development that’s expected; for always-on production, export the workflow to a server.

Real webhooks against a local instance turn a slow test loop into an instant one. Download ReDock and point your first webhook at your Mac.