TCP/UDP Tunnels

Expose local TCP and UDP services through Jetty, not just HTTP. Use this for databases, game servers, IoT devices, DNS, MQTT, SSH, or any protocol that runs over raw TCP or UDP.

Overview

By default, Jetty tunnels carry HTTP traffic. TCP and UDP tunnels forward raw network packets between the edge and your local machine. Instead of a public URL, TCP/UDP tunnels are assigned a dedicated public port on the edge server.

Creating a TCP tunnel

From the CLI

jetty share 3306 --protocol=tcp

This creates a TCP tunnel that forwards traffic from a public port to localhost:3306 (e.g. a MySQL server). The CLI output shows the assigned public port:

Connected to Jetty Bridge
Tunnel established

Your tunnel is live at:
  tcp://tunnels.usejetty.online:14823
  Forwarding to 127.0.0.1:3306

Press Ctrl+C to stop sharing.

From the API

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

The response includes protocol, assigned_port, and public_endpoint:

{
  "data": {
    "id": "01ABC...",
    "protocol": "tcp",
    "assigned_port": 14823,
    "public_url": "https://myapp.tunnels.usejetty.online",
    "public_endpoint": "tcp://tunnels.usejetty.online:14823",
    "local_target": "127.0.0.1:3306",
    "status": "awaiting_connection"
  }
}

Creating a UDP tunnel

jetty share 53 --protocol=udp

UDP tunnels work the same way but forward UDP datagrams instead of TCP streams.

Common use cases

Database access

Expose a local MySQL or PostgreSQL database for a teammate or staging app:

# MySQL
jetty share 3306 --protocol=tcp

# PostgreSQL
jetty share 5432 --protocol=tcp

Connect remotely using the assigned port:

mysql -h tunnels.usejetty.online -P 14823 -u root -p

SSH access

Share SSH access to your machine:

jetty share 22 --protocol=tcp

Connect remotely:

ssh user@tunnels.usejetty.online -p 14823

Game servers

Expose a local game server:

# Minecraft
jetty share 25565 --protocol=tcp

# Custom UDP game server
jetty share 7777 --protocol=udp

Redis / Memcached

jetty share 6379 --protocol=tcp

MQTT (IoT)

jetty share 1883 --protocol=tcp

Plan requirements

TCP/UDP tunnels are a paid feature with per-plan limits:

If you are on the free plan and try to create a TCP/UDP tunnel, you will receive a 422 error: "TCP/UDP tunnels are not available on your current plan." Upgrade in Bridge > Billing.

Permissions

Creating TCP/UDP tunnels requires the Manager role or higher. This is stricter than HTTP tunnels (which require Developer+) because raw protocol tunnels expose a public port and carry greater security implications.

Team owners can adjust this via per-team permission overrides. For example, to allow developers to create TCP tunnels on a specific team, set the create_raw_tunnel permission to developer in the team's permission overrides.

Team-level limits

Organization admins can set max_tcp_udp_tunnels per team to further restrict how many raw protocol tunnels each team can create. When set, this overrides the plan limit for that team. Configure this in Bridge > Teams > Team Settings.

Port allocation

TCP/UDP tunnels are assigned a random port from the configured range (default 10000-60000). The port is unique across all active tunnels and remains assigned for the lifetime of the tunnel.

If you delete the tunnel and recreate it, you may get a different port. Use the API response or CLI output to find the assigned port.

Dashboard

TCP/UDP tunnels appear in the tunnel list with a protocol badge (TCP or UDP). The monitor view shows the public endpoint as tcp://host:port or udp://host:port instead of an HTTPS URL.

Traffic statistics (bytes in/out, heartbeats) work the same as HTTP tunnels. Request-level inspection is not available for raw TCP/UDP traffic since there are no HTTP methods or status codes to capture.

Differences from HTTP tunnels

• No subdomain routing -- TCP/UDP tunnels use port-based routing, not Host header routing
• No request inspection -- raw protocol traffic is forwarded as-is without HTTP parsing
• No routing rules -- path/header-based routing does not apply to raw protocols
• No virtual endpoints -- mock responses are HTTP-only
• No basic auth -- HTTP basic auth does not apply to raw protocols
• No webhook signatures -- signature verification is HTTP-only
• IP allowlist/blocklist and rate limiting still apply

WebSocket protocol

For TCP/UDP tunnels, the edge sends raw data frames over the WebSocket connection instead of HTTP request/response messages:

{
  "type": "tcp_data",
  "connection_id": "uuid",
  "data_b64": "base64-encoded-bytes"
}

The CLI agent opens a local TCP/UDP connection and forwards data bidirectionally between the WebSocket and the local socket.

Related guides

• Sharing local sites -- HTTP tunnel creation
• Tunnel settings -- rate limits, timeouts, IP filtering
• API reference -- tunnel creation API with protocol parameter