Technical Specifications

A tunnel is an outbound-only connection from an environment to the rstream edge network. It exposes services without requiring inbound ports, public IPs, or NAT changes. Traffic is carried over an encrypted tunnel transport and can be published as Internet-facing endpoints or kept private for client-only access.

Connectivity starts from inside environments and goes out to the edge network. This avoids inbound exposure and keeps network changes minimal across local development, servers, and device fleets.

Identity and access policies are evaluated at the edge entrypoint so enforcement does not depend on each application stack or upstream environment.

Official clients and SDKs are shipped as multi-platform deliverables with a controlled build and packaging pipeline. This includes the CLI and the Go, C++, and JavaScript SDKs.

Published tunnels register an Internet-facing endpoint on the edge using HTTP, TLS, DTLS, or QUIC. Private tunnels do not expose a public endpoint and are dialed by ID or name using an rstream client.

Bytestream tunnels provide a TCP-like stream abstraction. Datagram tunnels provide a UDP-like message abstraction. The choice is independent from the transport used between client and edge.

Downstream refers to traffic between Internet clients and the edge on published endpoints. Upstream refers to traffic between the edge and the attached service. Downstream and upstream protocols can differ depending on tunnel configuration.

The client-to-edge connection is secured by rstream and is separate from any application TLS, DTLS, or QUIC used by the upstream service.

HTTP endpoints accept HTTP/1.1, HTTP/2, and HTTP/3 downstream. Upstream can be HTTP/1.1, clear-text HTTP/2 (h2c), HTTP/2 over TLS, or HTTP/3 over QUIC depending on configuration. HTTP ALPN is managed by the HTTP endpoint mode.

HTTP endpoints support WebSocket across h1, h2c, and h3 upstreams, with translation between downstream and upstream HTTP versions handled at the edge.

WebTransport is exposed through published HTTP/3 tunnels, including bidirectional streams, unidirectional streams, datagrams, and the HTTP authentication model at session establishment.

TLS endpoints accept generic TLS clients. TLS can be terminated at the edge with optional custom ALPNs, or forwarded end-to-end using TLS passthrough when upstream must own certificate and ALPN negotiation.

DTLS endpoints terminate DTLS at the edge. Upstream traffic is forwarded as datagrams by default, or as upstream DTLS when upstream TLS is enabled. Custom ALPNs are supported.

QUIC endpoints terminate QUIC at the edge and establish corresponding QUIC sessions upstream. Custom ALPNs can be configured and the negotiated ALPN is preserved upstream.

Published tunnels can request project-scoped stable domains such as <slug>-<project-endpoint>.t.<engine-host>. The engine validates project ownership and live tunnel uniqueness at creation time.

Roadmap item for attaching user-owned DNS names to tunnel projects with ownership verification and DNS configuration checks.

Private tunnels have no public forwarding address. Clients dial them by ID or name to carry internal protocols such as SSH or custom services.

rstream tunnels can act as a signaling layer for WebRTC and other real-time systems through tunnel labels, authenticated APIs, and event streams.

rstream provides a managed STUN and TURN service for ICE connectivity, with project-bound credentials issued through the platform API or derived locally from supported credential types.

Attach key and value labels to tunnels for discovery, filtering, and automation.

Carry legacy or custom protocols over bytestream or datagram tunnels without requiring upstream systems to change their network exposure.

The default client-to-edge tunnel transport uses a modern TLS 1.3 baseline.

Clients can also reach the edge over QUIC, independently from the protocol exposed on published tunnel endpoints.

Published TLS and HTTPS endpoints can be configured to accept TLS 1.2 and TLS 1.3 for client compatibility, with project policies able to raise the effective runtime minimum to TLS 1.3 where required.

Terminate TLS at the edge to apply authentication and policy before routing upstream.

Forward TLS end-to-end when upstream must own certificates and ALPN negotiation.

Use TLS, DTLS, or QUIC between the edge and the attached upstream service. HTTP upstream TLS keeps the HTTP negotiation model, while non-HTTP tunnels preserve the downstream ALPN when one is negotiated.

Published TLS, DTLS, and QUIC tunnels can advertise explicit ALPN values. HTTP endpoints keep ALPN tied to the configured HTTP version behavior.

Project policies can prefer or require ECH on terminated TLS surfaces, reducing exposure of SNI and ClientHello metadata where DNS and client support are present.

Project policies can prefer or require hybrid post-quantum key exchange, with an optional NIST and FIPS-oriented hybrid group restriction.

Developer and operator credentials created, rotated, and revoked from the dashboard.

Client ID and secret credentials for backends that mint least-privilege tokens for products and automation.

Least-privilege tokens that scope discovery, creation, and access down to tunnel properties and access paths.

HTTP endpoints can require a scoped token at the edge before any request is routed upstream.

HTTP endpoints can require browser-based rstream account authentication at the edge for human access flows.

Edge entrypoints can require client certificates to establish machine identity before traffic is routed upstream.

HTTP endpoints can enforce an interactive challenge before access is granted.

Apply GeoIP-based restrictions at the entrypoint.

Allow or deny traffic based on IP ranges.

Roadmap item for rate limiting connection attempts or requests per IP.

Roadmap item for bandwidth, volume, time, and HTTP body limits enforced at the edge.

API resources for clients and tunnels with listing, filtering, and lifecycle operations.

Real-time feeds over SSE or WebSocket reflecting changes to clients and tunnels.

Event delivery to user-defined HTTP endpoints.

Connection logs and HTTP activity logs for incident analysis and operational debugging.

Create, rotate, and revoke operator tokens and application credentials.

View tunnels, endpoint types, visibility, labels, and key identity or policy flags.

Open browser-based terminals to rstream WebTTY servers registered in the control plane.

Web-native terminal protocol carried over rstream tunnels.

Run an rstream WebTTY server on machines to expose terminal access without inbound ports.

Access sessions from the browser, CLI, or SDK integrations with identity enforced at the edge.

Roadmap item for user-controlled encryption keys for terminal content.

Use a netcat-like helper from the C++ SDK as an SSH ProxyCommand to route SSH over a bytestream tunnel for remote access without inbound exposure.

Expose legacy services through outbound-only tunnels without changing upstream network exposure.

Create a single endpoint from CLI arguments for interactive developer workflows, demos, and ad-hoc remote access.

Keep tunnels in sync from a YAML configuration.

Discover and manage tunnels from Docker labels.

Roadmap item for Kubernetes-first tunnel workflows.

Standalone binaries and packaging across Linux, macOS, Windows, and BSD variants.

A free engine edition that runs independently and does not require an rstream account.

Deploy inside existing environments to keep traffic and operations within infrastructure you operate.

Run on bare metal, Docker, or Kubernetes depending on operational standards.

Reference implementation with the broadest protocol and feature coverage. The CLI codebase lives in the Go repository.

Native integration designed around Boost.Asio with a focus on bytestream tunnels and latency-sensitive workloads.

Control plane API access, tunnel inventory, and event-driven integrations. Tunnel creation is not available yet.

Roadmap item for tunnels-first workflows in Python environments.

Roadmap item for executing LLM-generated workloads in isolated microVMs.

Roadmap item for workloads that require direct filesystem access during execution.

Roadmap item for controlled network connectivity carried through rstream tunnels.

Roadmap item for native, Docker-based, and Kubernetes-based runners, with Firecracker-backed execution where applicable.

Event-driven I/O and multiplexed tunnels are designed to minimize added latency on top of network RTT.

Multi-region entrypoints keep connectivity close to users and systems.

Roadmap item for additional edge-side distribution and availability behavior.