Remote development is great. Your devs work from Bali, Berlin, or Boston. But when they connect through a VPN and start testing webhooks — mayhem can follow. Your integrations break. Webhooks silently fail. Even worse, debugging becomes a wild goose chase.
TL;DR:
Webhooks can break when remote developers are on VPNs, especially if their environments aren’t reachable by public web services like Stripe, GitHub, or Twilio. The solution? Architect secure, whitelisted tunnels or relay servers that safely expose local environments without compromising security. This keeps your integrations smooth and your devs happy. Keep it simple, stay connected, and think like a router ninja.
Wait, why do webhooks break anyway?
Let’s say a dev is working on a payment flow that Stripe uses a webhook to notify your app about. Locally, they’re fine. But through a VPN, things get tricky. Suddenly:
- Requests from Stripe never reach the dev’s local server
- Webhook retries pile up and timeout
- Your logs are quiet, but not in a good way
This usually happens because the webhook provider (like Stripe or GitHub) can’t reach the dev’s local machine. Either the VPN masks their IP or blocks ports. Or maybe your dev is running a tunnel that isn’t resilient or secure.
But my devs are using tunneling tools!
Great start! Tools like ngrok, Cloudflare Tunnel, or Localtunnel are popular. They help expose local servers to the outside world temporarily. But they have some downsides:
- Random URLs – URLs change every time unless you pay for custom domains
- Security – Open to everyone unless you set a password (and nobody remembers to)
- Performance – Not always the fastest or most reliable for high-volume testing
- Breakage – VPNs can interfere with the port forwarding or route resolution
So, what’s the secure way to do this?
You need a system that:
- Lets devs receive real webhooks
- Keeps your internal network safe
- Persists across dev reboots
- Is easy to manage, monitor, and restrict
In other words, something secure, predictable, and whitelistable.
Enter the relay tunnel architecture
Instead of exposing every dev’s laptop to the world (scary!), build or use a centralized webhook relay. Here’s how it works:
- Set up a secure public-facing webhook gateway
- This gateway receives all webhooks from trusted providers
- It then forwards each webhook to the correct developer tunnel or endpoint
The public gateway is the only thing that needs to be whitelisted by GitHub, Stripe, or Twilio. Your actual dev tunnels remain hidden and safe.
Bonus: You can log and inspect every webhook coming through the relay!
Basic flow looks like this:
Provider (e.g. Stripe) ---> Public Relay ---> Dev Tunnel ---> Localhost
Okay, but how do I build this?
There are several options. Some are DIY, others are hosted.
Option 1: Use a Hosted Relay (Simple to Start)
- Webhook Relay – Works like a charm with custom destinations
- Smee.io – Popular with GitHub, but not secure by default
- Hookdeck – Polished UI and analytics, great for teams
These tools act as the public interface. Your developers each get their own channel or proxy. The service then relays the webhook to the dev’s machine. Usually via another tool like ngrok or through persistent WebSocket connections.
Option 2: Roll Your Own (Advanced Mode)
If you want full control (maybe for compliance reasons), you can build your own system. Here’s the basic set of components:
- Public Ingress Server: A public API endpoint where providers send hooks
- Routing Logic: Determine which webhook goes to which dev (based on token, endpoint, or URL path)
- Tunnel Client: Each dev runs a tiny daemon that connects securely to the ingress and receives hooks forwarded via HTTPS or WebSocket
Use JWTs or signed tokens to ensure only authenticated clients receive the data. Add SSL and per-dev logging.
The VPN Problem (And Fix)
When a dev is on a VPN, their routing table changes. DNS might resolve differently. External webhook services might see the VPN IP and think, “Nope, blocked.”
In this case:
- Tunnel connections might drop
- Webhook services can’t reach the tunnel’s public address
- Security tools block unencrypted traffic
The best workaround is to have tunnels that initiate outbound from the dev machine. VPNs usually allow outbound traffic. WebSocket-based clients work well here.
Also, avoid dynamic DNS or random URLs. Try to assign predictable subdomains with valid SSL certs.
Best Practices
Here’s how to keep things smooth and secure:
- Use TLS – Always encrypt all webhook payloads
- Use API tokens – Validate each webhook source
- Log failed events – Replay them manually for testing
- Expire outdated tunnels – Don’t leave things open forever
- Monitor traffic patterns – Catch noisy or malformed integrations early
Dev Experience Matters
If this process is hard, your devs will skip it. They’ll test without real webhooks. Bugs will sneak into production.
Invest in tooling that:
- Is easy to run (1 command)
- Supports local logs and inspecting payloads
- Has replay and throttling options
- Works across environments and VPNs
TLDR v2 (Just in case you scrolled too fast)
Remote devs on VPNs often break webhook integrations. Instead of connecting every dev device directly to the internet, build or use a secure, auth-protected webhook relay. It forwards only verified payloads to the correct dev environment. This protects your perimeter while keeping productivity high.
Your Homework
Build a minimal relay prototype in the next sprint. Pick a hosted service if you're getting started or prototypes are urgent. For mature teams, consider building your own with persistent tunnels and strict auth. Bake it into your dev workflow. Your integrations (and your future self) will thank you.
Bonus: Put a funky sound every time a webhook hits the dev machine. Webhooks + dopamine = magic!
