Tunnel Settings

Configure per-tunnel options for performance, security, and lifecycle management. These settings are available from the tunnel detail view in Bridge.

Overview

Each tunnel has configurable settings that control how traffic is handled. Settings are grouped into sections:

• Performance and redaction -- rate limits, timeouts, body size caps, and header redaction.
• Password protection -- require HTTP basic auth to access the tunnel.
• Webhook signature verification -- validate incoming webhook signatures before forwarding.
• Expiry -- automatically stop a tunnel after a set time.

Accessing tunnel settings

1. Open Bridge and go to the Tunnels tab.
2. Click Monitor on the tunnel you want to configure.
3. Scroll down to the Tunnel Settings section.

Settings are only editable by team members with the Developer role or higher.

Performance and redaction

Redaction tier

Controls which HTTP headers are stripped from request samples before they are stored. Choose from:

Upstream timeout

How long (in seconds) the edge waits for your local app to respond before returning a timeout error to the client. Range: 1--300 seconds.

Rate limit

Maximum requests per second the tunnel will accept. Requests above this rate are rejected with a 429 Too Many Requests response. Leave blank to use the plan default.

Max body size

Maximum request body size in bytes. Requests with bodies larger than this limit are rejected with a 413 Payload Too Large response. Leave blank to use the plan default.

Password protection

Add HTTP basic auth to your tunnel so only people with the credentials can access it. This is useful for staging environments, client demos, or any tunnel you want to restrict.

Setting up basic auth

1. In the Password Protection section, enter a Username and Password.
2. Click Save.
3. Visitors to your tunnel URL will see a browser login prompt.

Removing basic auth

Clear both the username and password fields and save. The tunnel will be publicly accessible again (subject to any other access controls).

Basic auth credentials are stored securely -- passwords are hashed and never displayed in plain text after saving.

Webhook signature verification

Verify incoming webhook signatures at the edge before forwarding requests to your local app. This ensures only legitimate webhook payloads reach your development server.

Supported providers

Configuring webhook verification

1. Select a Provider from the dropdown.
2. Enter the Signing secret from your webhook provider's settings.
3. For Custom HMAC-SHA256, also specify the Header name that contains the signature.
4. Click Save.

Requests with invalid or missing signatures are rejected before reaching your local app.

When to use this

• During webhook development, to catch misconfigured signing secrets early.
• When sharing a tunnel URL publicly -- prevents random traffic from triggering your webhook handlers.
• To replicate production-like signature validation in your local environment.

Tunnel expiry

Tunnels can be configured with an expiration time. When the expiry is reached, the tunnel is automatically stopped.

Viewing expiry

If a tunnel has an expiry set, it appears as a banner in the tunnel detail view showing the remaining time and the exact ISO 8601 timestamp.

Removing expiry

Click Remove expiry in the expiry banner to clear the expiration. The tunnel will remain active until manually stopped or deleted.

Setting expiry from the CLI

Use the --expires flag when starting a tunnel:

jetty share 3000 --expires=30m

Supported duration formats:

Setting expiry via the API

Use the expires_in parameter (in seconds) when creating or attaching a tunnel:

curl -X POST https://usejetty.online/api/tunnels \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"local_port": 3000, "expires_in": 1800}'

The expires_in value must be between 60 (1 minute) and 604800 (7 days).

Expiry is useful for time-limited demos, temporary webhook endpoints, or automated CI/CD tunnels that should clean up after themselves.

Custom error pages

When a tunnel is unavailable (no agent connected or the upstream is not responding), the edge serves a default error page. Organizations can replace this with a custom HTML page for a branded experience.

Configuring custom error pages

1. Navigate to Organization --> Settings --> Custom Error Pages.
2. Paste your HTML into the editor.
3. Click Save.

The custom page is served by the edge on 502 Bad Gateway and 504 Gateway Timeout errors for all tunnels in the organization.

Template variables

You can include dynamic values in your HTML using template variables:

Example:

<!DOCTYPE html>
<html>
<body>
  <h1>Service Unavailable</h1>
  <p>The tunnel <strong>{{subdomain}}</strong> is not responding.</p>
  <p>Error: {{error_code}} at {{timestamp}}</p>
  <p>Please try again in a few moments.</p>
</body>
</html>

Custom error pages are stored per organization. If no custom page is configured, the default Jetty error page is shown.

Related guides

• Routing rules -- route requests to different upstreams.
• Traffic inspection -- view and replay captured requests.
• API tokens -- configure token-level redaction settings.
• Webhook testing -- end-to-end webhook development workflows.