Create a Tunnel

The rstream forward command is the primary entrypoint for opening tunnels from the CLI. It runs an agent next to a local service, creates a tunnel on the engine, and forwards traffic from the tunnel endpoint to a local target.

This page focuses on the workflow and the most common options. Protocol details and edge authentication are covered in the Tunnels section.

Basic usage

A minimal tunnel forwards to localhost:8080:

rstream forward 8080

The target can be provided as port or host:port. When no argument is provided, the default target is localhost:8080.

A tunnel name can be provided to make the tunnel easier to identify:

rstream forward 8080 --name dev-api

Stable domains

Published tunnels normally receive an automatically allocated endpoint. When a stable public URL is required, provide a hostname from the project namespace with --host:

rstream forward 8080 --host api-<project-endpoint>.t.<engine-host>

The engine validates that the requested hostname belongs to the current project and is not already used by another live tunnel. See the stable domains guide for the exact shape, reconnect behavior, and declarative configuration examples.

Publishing and private tunnels

Published tunnels expose an Internet-reachable endpoint on the edge network. Private tunnels are not exposed publicly and require an rstream client or SDK to connect.

The rstream forward command can create a non-published tunnel:

rstream forward 8080 --no-publish

Private tunnels and rstream dialers are covered in Private Tunnels.

Selecting a protocol

The engine supports multiple tunnel protocols. HTTP is the default for published tunnels, and it is the most feature-complete option because it supports HTTP routing, connection upgrades, and edge authentication.

Non-HTTP protocols are useful for custom traffic, transport-level TLS behavior, datagrams, and application protocols that already define their own framing. Protocol selection is exposed as one mutually exclusive flag on rstream forward.

--http creates a published HTTP tunnel. This is the default and is the right starting point for web apps, APIs, WebSocket, WebTransport over HTTP/3, and request-level authentication at the edge.

--tls creates a published TLS tunnel for non-HTTP bytestream protocols. It is used when the edge must terminate TLS, pass TLS through, enforce mTLS, or negotiate custom ALPN values.

--dtls creates a published DTLS tunnel for datagram protocols that need DTLS at the edge.

--quic creates a published QUIC tunnel for QUIC-native application protocols with application ALPN negotiation.

HTTP is the default for published tunnels. DTLS and QUIC require an engine deployment where the corresponding listeners are enabled.

Common example

With a local HTTP server running on port 8080, open a tunnel and test it with curl using the endpoint printed by the CLI:

rstream forward 8080 -o text

Once the tunnel status is online, send requests to the forwarding URL shown by the command. The forwarded field shows the local target that receives those requests.

Where to go next

For production behavior of HTTP tunnels, including HTTP versions and edge authentication, see HTTP Tunnels. For transport settings such as proxy support and DNS overrides, see Tunnel Transports.