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 with ALPN, or HTTP/3 over QUIC depending on configuration.

HTTP endpoints support upgrade-based protocols such as WebSocket when upstream is configured accordingly.

WebTransport is supported on QUIC-published tunnels. It is not exposed through HTTP published endpoints.

TLS endpoints accept generic TLS clients. TLS can be terminated at the edge or forwarded end-to-end using TLS passthrough.

DTLS endpoints terminate DTLS at the edge. Upstream traffic is forwarded to the attached service as datagrams.

QUIC endpoints terminate QUIC at the edge and establish corresponding QUIC sessions upstream when configured.

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

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.

Client-to-edge tunnel transport uses a modern TLS baseline.

Published TLS and HTTPS endpoints can be configured to accept TLS 1.2 and TLS 1.3 for client compatibility.

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.

Roadmap item to reduce passive observability of SNI and ClientHello metadata where supported.

Roadmap item for hybrid key exchange in tunnel transport.

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.