Bidirectional Tunnels: Proxy Outbound Requests Through Hookbase

Tunnels in Both Directions

Hookbase tunnels have always worked in one direction: external webhooks arrive at Hookbase and get forwarded to your local machine over a WebSocket connection. This is essential for local development -- you can test webhook integrations without deploying or exposing your machine to the internet.

Today we are adding the reverse path. Bidirectional tunnels let your local machine send HTTP requests through Hookbase to external services. The request travels over the same WebSocket connection, gets executed by Hookbase's edge infrastructure, and the response comes back to your local app.

Why Outbound Proxying?

Some services are only reachable from certain networks. Maybe the staging API is behind a VPN, the IoT device is on a private network, or the partner's sandbox only accepts traffic from whitelisted IPs. Setting up a VPN or SSH tunnel for quick testing is overkill.

With bidirectional tunnels, your local development environment can reach these services through Hookbase:

• Internal APIs -- Access staging or internal services from your laptop without VPN
• IoT devices -- Send commands to devices behind NAT or corporate firewalls
• Partner sandboxes -- Reach test environments that whitelist Hookbase's IPs
• Cross-network debugging -- Call services on different networks without infrastructure changes

How It Works

Setup

1. Create a tunnel with Direction set to "Bidirectional"
2. Add the target hostnames to the Allowed Hosts list (up to 20)
3. Connect with the CLI using hookbase tunnel

Request Flow

1. Your local app sends a request to the CLI's local proxy endpoint
2. The CLI wraps it as an outbound_request message and sends it over the WebSocket
3. Hookbase's Durable Object validates the target host against your allowed list
4. The Durable Object makes the HTTP request to the target URL
5. The response travels back over the WebSocket to the CLI
6. The CLI returns the response to your local app

The entire round-trip uses the existing WebSocket connection -- no additional ports, no extra configuration.

Allowed Hosts

Every bidirectional tunnel requires an Allowed Hosts list. This is a security measure that prevents the tunnel from being used as an open proxy. Only requests to hostnames explicitly on your list will be forwarded. Requests to any other hostname are rejected with an error.

You can manage allowed hosts in the dashboard when creating or editing a tunnel, or via the API.

Security Model

Bidirectional tunnels maintain the same security properties as inbound tunnels:

• Authenticated connections -- Only authenticated CLI sessions with valid API keys can connect
• Host validation -- Outbound requests are checked against the allowed hosts list before execution
• No port exposure -- All traffic runs over WebSocket; no inbound ports are opened on your machine
• Audit logged -- All outbound requests through the tunnel are logged for visibility

Availability

Bidirectional tunnels are available on Pro plans and above. Inbound-only tunnels remain available on all plans.

To get started, create a tunnel in the dashboard with direction set to "Bidirectional", add your target hosts, and connect with the CLI.