Changelog

Tunnel projects now support webhooks for delivering lifecycle events to HTTPS endpoints.

This makes runtime tunnel state easier to connect to durable systems. A tunnel or client can be short-lived by design; with webhooks, applications can persist the lifecycle around it, update an inventory, react to labels, or clean up state when a published tunnel disappears.

The first event catalog covers client.created, client.deleted, tunnel.created, and tunnel.deleted. Connection logs and traffic summaries remain out of webhook delivery so high-volume observability data stays in logs and event inspection surfaces.

Webhook endpoints are available on Pro and Enterprise projects. The dashboard includes endpoint creation, event selection, signing secret rotation, delivery health charts, delivery filtering, request payload inspection, response details, and delivery attempt history.

The Control plane API and MCP expose the same split used in the dashboard: project events are the canonical lifecycle records, while webhook deliveries and attempts are the per-endpoint delivery diagnostics.

The rstream CLI also supports webhook-shaped local delivery starting with v1.21.0. rstream events --webhook can forward live project events to a local receiver with the same signed JSON body and headers used by configured webhook endpoints, which makes receiver development easier before registering a durable endpoint.

See Webhooks for payloads, signatures, retries, permissions, and delivery inspection.

rstream now gives Codex a native way to reach the resources around a repository: local services, hosted project state, remote machines, remote-local services, bounded filesystem roots, and device-local MCP servers.

The Codex integration requires rstream CLI 1.19.0 or later.

There are two MCP surfaces with different trust boundaries. The hosted /api/mcp endpoint is for Control plane work: discovery, identity, workspaces, projects, plan and usage data, logs, TURN, stable domains, settings, token minting, and explicit project creation or checkout. It uses bearer-token authentication and the same permission and resource boundaries as the API.

The local CLI server is the agent runtime surface. rstream codex setup registers rstream mcp serve, which reuses the operator's local rstream context and private tunnel dialer. Codex can expose a local development server, inspect WebTTY machines behind NAT, run non-interactive remote commands, use the WebDAV filesystem sidecar when it is enabled, expose a service that only listens on the remote host, and bridge a device-local MCP server without opening inbound ports on that device.

This changes the Codex workflow from repository-only automation to controlled connectivity. Codex can check plan and usage state before using a feature, ask before billing-sensitive or mutating operations, publish a temporary URL for a local service, gather logs from labeled remote devices, move files through an explicit filesystem root, bridge device-local MCP tools, and clean up the tunnels it created.

The token model is now explicit in the MCP docs and tool descriptions. Developer workstations use the rstream login credential and linked contexts. Remote devices use project-scoped credentials when they need their own durable access. Short-lived delegated tokens are kept for immediate URL, browser, published MCP, or runtime handoff flows.

The WebDAV sidecar is still a filesystem boundary, not a sandbox. It is opt-in, rooted by --fs-root, and runs with the WebTTY server process permissions. For remote agent runtimes that cannot start a local stdio MCP process, rstream mcp publish can expose the same local MCP surface as a token-protected Streamable HTTP endpoint at /mcp.

See Codex, Agent Native, WebTTY, and Use rstream as a Connectivity Layer for Codex.

Hosted rstream tunnel projects now include higher monthly bandwidth quotas on Basic and Pro.

This gives small projects more room to test real workloads on Basic and makes Pro a better fit for sustained development, staging, remote access, and WebRTC traffic without moving to a custom Enterprise agreement only because of bandwidth.

Basic projects now include 5 GB per month for rstream tunnels bandwidth and 5 GB per month for TURN relay bandwidth. The Basic simultaneous tunnel limit remains unchanged at 2 tunnels.

Pro projects now include 200 GB per month for rstream tunnels bandwidth and 200 GB per month for TURN relay bandwidth. The Pro simultaneous tunnel limit remains unchanged at 50 tunnels. Enterprise projects continue to use custom limits.

Tunnel bandwidth and TURN relay bandwidth continue to be tracked as separate usage metrics. For Basic and Pro, both quota buckets use the same monthly value for the plan.

No protocol or feature gates changed with this update. For current plan limits, refer to Pricing. For TURN relay behavior and usage reporting, refer to STUN and TURN.

rstream now supports plain HTTP CONNECT for upstream forward proxy services, plus MASQUE CONNECT-UDP and CONNECT-IP sessions on published HTTP/3 datagram tunnels.

This extends the HTTP tunnel model beyond WebSocket and WebTransport. A published HTTP tunnel can carry TCP proxying with plain CONNECT, and a published HTTP/3 tunnel can carry UDP proxying with CONNECT-UDP or IP packet proxying with CONNECT-IP, while keeping the usual HTTP entrypoint behavior: edge authentication, access policy checks, project routing, observability, and tunnel lifecycle remain in the same path.

For plain CONNECT, the engine forwards CONNECT host:port to the upstream proxy and relays opaque TCP bytes only after the upstream returns 2xx. The CONNECT target is never used for tunnel routing; it remains an upstream proxy policy decision.

For MASQUE, the engine acts as an HTTP/3 Extended CONNECT relay. It validates HTTP/3 and datagram support on both sides, opens a matching upstream session to the service attached by the rstream client, and relays request-stream capsules plus HTTP datagrams end-to-end. UDP target handling, DNS resolution, IP route assignment, and packet policy remain owned by the upstream MASQUE service.

The Go SDK repository includes runtime tests for plain CONNECT over H1, H2, and H3, plus MASQUE samples built with quic-go/masque-go and quic-go/connect-ip-go. The MASQUE examples can run privately through the SDK datagram dialer, or through a published HTTP/3 endpoint with --publish.

See Connection Upgrades, Tunnel Protocols, Go SDK, and Build a Private Residential Egress Gateway with MASQUE and rstream for setup details and an end-to-end egress gateway walkthrough.

References:

Plain CONNECT RFC 9110 §9.3.6, CONNECT-UDP RFC 9298, CONNECT-IP RFC 9484, HTTP Datagrams and capsules RFC 9297.

The self-hosted rstream Engine CE documentation has been rewritten around a deployable operating model.

The documentation now explains the CE runtime boundary, the difference between the engine and the hosted Control plane, the DNS model for the base engine host and .t.<engine-host> tunnel hostnames, the static TLS certificate requirements, JWT agent authentication, Prometheus protection, and the CE feature boundary.

A new step-by-step guide walks through a complete Docker Compose deployment. It starts rstream-engine-ce, signs a local JWT, serves a local TLS certificate, runs an upstream HTTP service, launches a separate validation agent, publishes a tunnel, verifies the Engine API, checks Prometheus, calls the published tunnel hostname, and validates certificate reload without restarting the engine. It then maps the same shape to a production domain, ACME DNS validation, a certificate renewal sidecar, production agent token creation, and production smoke checks.

The guide also documents the production substitution for TLS: an ACME sidecar can write renewed cert.pem and key.pem files into the shared TLS directory, and the CE static certificate provider will reload them on later TLS handshakes.

See Self-Hosted, Deployment, Configuration, Operations, and Self-Host rstream Engine CE with Docker Compose.

rstream now supports hardened storage for the credentials used by agents and SDK runtimes when they authenticate to the engine control channel.

The Go CLI and Go SDK can store bearer tokens in macOS Keychain, so local configuration files keep a Keychain reference instead of the token value. The same macOS provider can also load an mTLS client identity from Keychain by certificate SHA-256 fingerprint, letting the signed rstream binary use the private key without copying it into the YAML file.

For certificate-backed agent authentication outside macOS, the Go SDK and C++ SDK now support PKCS#11 mTLS storage. Agents can authenticate with a private key held by a YubiKey, HSM, smart card, TPM-backed module, or SoftHSM validation token. The configuration names the PKCS#11 module, token selector, key selector, certificate source, and the environment variable that supplies the PIN. C++ agents can also set the OpenSSL provider name when distribution packaging exposes it under a name such as pkcs11.

JavaScript SDK configuration parsing has also been updated to understand the shared credential storage shape. Unsupported hardened storage modes fail explicitly instead of being ignored, which keeps cross-SDK configuration behavior auditable.

This release hardens agent authentication. Published tunnel mTLS remains a separate surface: when a public tunnel requires mTLS, the connecting client still needs its own client certificate provisioning.

For reference fields and support matrix, see Credential Storage. For an operational walkthrough, see Secure rstream Agent Authentication with Keychain and PKCS#11.

rstream now has a Kubernetes operator for managing tunnels from cluster-native resources.

The operator introduces two custom resources. RstreamConnection describes how a namespace reaches rstream, usually by project endpoint so the operator can resolve the current engine through the Control plane. RstreamTunnel describes how a Kubernetes Service should be exposed, including protocol, Service port, publishing mode, HTTP settings, labels, and access policy.

This is useful when tunnel configuration should follow the same lifecycle as Deployments and Services. A preview environment can expose its HTTP Service as soon as the namespace is applied. An internal admin tool can keep a stable rstream address without an Ingress controller or inbound firewall rule. Homelab, field-device, embedded, robotics, and drone deployments can publish outbound-only services even when they sit behind NAT, cellular networks, or customer firewalls. A platform team can give application teams a small Kubernetes API while keeping the tunnel agent, RBAC, credentials, status, and runtime behavior standardized.

The operator creates a dedicated agent Deployment per tunnel. The manager reconciles Kubernetes resources and validates references; the agent opens the outbound rstream connection, forwards traffic to the Service, and writes readiness plus the forwarding address back to RstreamTunnel.status.

Self-hosted deployments are supported too. Hosted users normally set projectEndpoint and let the Control plane resolve the engine. Self-hosted users can set engine directly when no Control plane or project model exists.

For setup details, see Kubernetes Operator, Declarative Tunnels, and the step-by-step guide Expose a k3s Service with the rstream Kubernetes Operator.

rstream now supports certificate-backed authentication for agent connections and published tunnel traffic. Machines, devices, services, and external clients can now identify with a private key instead of carrying a bearer token.

The new mTLS Client Certificate (MTLS) credential stores the SHA-256 fingerprint of a client certificate and carries the Engine API permissions and Tunnel access rules for that certificate. The same credential can authorize an agent on the engine control channel, or a client reaching a published tunnel when mtls_auth is enabled. The private key stays outside rstream with the runtime that owns the identity, while admission remains managed from the same credential inventory as PATs and application credentials.

mTLS operates at the transport layer, so it is not limited to HTTP. For published tunnels, the same certificate-backed identity model can protect TLS, DTLS, and QUIC traffic regardless of the application protocol above it, including protocols such as gRPC or MQTT. Token authentication remains useful for HTTP clients; mTLS covers a broader set of runtimes and protocols.

The CLI and SDK configuration now expose mTLS as an alternative to token authentication for agent connections. A context may use token auth or mTLS auth for the engine control channel, but not both at once. The Engine HTTP API remains token-authenticated. Published tunnels may enable several authentication methods for different clients, but a single request must not present multiple proofs at the same time.

This requires rstream CLI and Go SDK 1.15.0 or later, and C++ SDK 1.7.0 or later.

For setup details, see mTLS, Configuration File, and Environment Variables.

References:

TLS 1.3 RFC 8446, DTLS 1.2 RFC 6347, QUIC transport RFC 9000.

rstream publishes its client SDKs and reference examples as open source repositories.

This release covers the code that runs on the user's machine or inside their infrastructure. The Go CLI and SDK, JavaScript SDK, C++ SDK, Kubernetes operator, WebTTY helpers, TURN helpers, and reference applications can now be reviewed directly on GitHub.

That visibility is especially important for tunnel software. A tunnel producer often runs on a developer machine, a customer server, an embedded device, a CI runner, or another private environment. It can hold short-lived credentials, open local services to a project, create published or private tunnels, dial private resources, request TURN credentials, and handle WebTTY sessions. Teams should be able to inspect that runtime path before they trust it in production.

The examples repository follows the same standard. The samples are meant to stay readable, but not at the cost of hiding security-critical decisions. The WebRTC examples show short-lived producer tokens, short-lived viewer tokens, scoped tunnel resources, backend-issued TURN credentials, WebRTC signaling through rstream tunnels, and user-to-device authorization owned by the application.

Two new guides document that video path end to end. Build Device-to-Browser Video Streaming with WebRTC and rstream starts from a standalone Go producer that publishes its viewer through an rstream tunnel and uses a state-of-the-art WebRTC stack for low-latency device streaming, including adaptive behavior and network recovery. Build a Next.js WebRTC Video Platform with rstream then moves product responsibilities into a Next.js backend, including device inventory, producer provisioning, viewer authorization, TURN issuance, and live tunnel state.

For SDK usage, start with the Go SDK, JavaScript SDK, and C++ SDK documentation.

rstream now exposes the product through agent-readable discovery, authentication, API, and workflow contracts.

This means an agent can start from the public site, discover the API catalog, learn how OAuth authentication works, fetch hosted and engine OpenAPI contracts, load rstream task skills, then act against the product with user-approved access. The intended path covers practical workflows such as selecting or creating a project, configuring the CLI, opening a published HTTP tunnel, setting up WebTTY, reading live engine inventory, and diagnosing setup failures.

The discovery layer is published through standard web entrypoints. The homepage advertises useful resources with Link response headers. /.well-known/api-catalog points to the hosted OpenAPI contract, engine OpenAPI contract, API documentation, and status endpoint. OAuth metadata is available through /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource. Agent Skills are indexed at /.well-known/agent-skills/index.json, and the MCP Server Card is available at /.well-known/mcp/server-card.json.

The API contracts now separate Control plane API operations from Engine API operations. /api/openapi.json describes automation-facing hosted APIs, including project creation and project resolution. /api/engine/openapi.json describes the engine endpoints for clients, tunnels, SSE, and WebSocket state. Both contracts expose rstream permission metadata so agents can choose practical scope bundles instead of guessing from endpoint names.

The CLI also gained more automation-friendly output paths and a structured diagnostic command. rstream login -o json, rstream project use -o json, context commands, list commands, events, and forward flows can now be consumed more reliably by agents and CI. rstream doctor -o json, available in rstream CLI 1.14.0 and later, provides a structured readiness check after setup changes or during troubleshooting without printing token values.

For the complete model, see Agent Native, APIs, and CLI Workflow.

HTTP tunnels can now require a browser challenge before traffic is forwarded upstream.

Challenge mode adds an automated browser verification step at the edge. When a browser reaches a protected HTTP tunnel without a valid challenge session, the engine redirects it to an rstream verification page, runs the challenge, then returns to the original tunnel URL.

The check happens before rstream Auth, so it can reduce unwanted automated traffic before account-based authentication is evaluated. A valid and authorized bearer token remains the machine-client path and can proceed without the browser challenge.

Challenge sessions use a dedicated cookie scoped to the tunnel host. They are independent from rstream Auth sessions, which keeps browser verification and user identity separate even when both controls are enabled on the same tunnel.

Challenge mode is available for HTTP tunnels with rstream forward --http --challenge-mode when the engine has an active challenge backend configured.

For behavior details and setup notes, refer to the Challenge Mode guide.

Published tunnels can now request a stable domain instead of relying only on a generated endpoint.

Each tunnel project owns a domain namespace under its engine host. A tunnel can request a hostname in that namespace, such as api-<project-endpoint>.t.<engine-host>, and the engine validates that the requested value belongs to the same project before accepting it.

This keeps public URLs stable across tunnel recreation when a service has a known identity. It also preserves the existing allocation model: if no hostname is provided, the engine still allocates a standard tunnel endpoint automatically.

The runtime protocol now returns hostname and port separately. The older host value remains available for compatibility, but new clients should use the explicit fields.

The CLI also keeps a generated stable domain during reconnect and reconcile loops when the user did not provide a hostname, reducing URL churn during short disconnects.

Stable domain support in rstream forward, rstream run, and WebTTY flows is available in rstream Go CLI 1.13.0 and later.

For setup details and validation rules, refer to the stable domains guide.

QUIC is now available as the transport between an rstream client and the edge.

The published side of the tunnel does not change. A project can still expose HTTP, TLS, DTLS, or QUIC endpoints while the publishing client carries its control channel and upstream traffic over a single QUIC connection instead of TLS over TCP.

This is a better fit for unstable paths, environments where TCP recovery is expensive, and datagram-heavy workloads. DNS override, DNS over TLS, DNSSEC validation, and address-family controls remain available on the transport side.

Transport selection is opt-in and depends on cluster support. Existing workflows can keep the default TLS transport, while CLI contexts and SDK clients can switch to QUIC where it provides better behavior.

CLI context support for QUIC tunnel transport is available in rstream Go CLI 1.12.0 and later.

For transport semantics and configuration examples, refer to Tunnel Transports.

References:

QUIC transport RFC 9000, QUIC TLS RFC 9001, DNS over TLS RFC 7858, DNSSEC RFC 4033.

Published HTTP/3 tunnels carry WebTransport, and WebSocket handling spans the full upstream HTTP matrix.

For WebTransport-compatible real-time systems, this keeps WebTransport on the standard HTTP tunnel path. Sessions can stay on published HTTP endpoints and keep the HTTP policy model at the edge, including token authentication, rstream Auth, and access policies, instead of moving to raw QUIC endpoints just to obtain streams and datagrams.

WebTransport is available on published HTTP tunnels configured for h3. WebSocket support now covers H1, H2C, and H3 upstreams, with protocol translation handled at the edge between downstream and upstream HTTP versions.

The main operational change here is WebTransport on the HTTP tunnel model. The broader WebSocket compatibility closes gaps for HTTP/2 and HTTP/3 upstream services at the same time.

The related CLI workflows are supported by rstream Go CLI 1.11.0 and later.

For the protocol matrix and setup details, refer to Connection Upgrades.

References:

WebSocket RFC 6455, WebSocket over HTTP/2 RFC 8441, WebSocket over HTTP/3 RFC 9220.

Encrypted Client Hello (ECH) is available as a project setting for TLS traffic terminated by the edge.

That makes it possible to hide SNI and ClientHello metadata without rolling separate changes through every application. One project keeps a consistent ECH posture across published endpoints and project-scoped engine surfaces that terminate TLS.

The setting supports preferred and required. preferred uses ECH when the client and DNS path support it, while keeping the standard TLS fallback path available. required rejects non-ECH handshakes and therefore limits the affected terminated surfaces to TLS 1.3 traffic.

ECH depends on valid DNS HTTPS or SVCB publication for the project hostname and on engine-side ECH configuration for the cluster. TLS passthrough remains excluded because the edge does not terminate the handshake. Community Edition deployments do not enforce this policy.

rstream Go CLI 1.12.0 and later includes the transport-side behavior needed for ECH-aware CLI workflows.

For the runtime policy model and transport-side DNS behavior, refer to Access Policies and Tunnel Transports.

References:

TLS Encrypted Client Hello RFC 9849, ECH configuration in DNS RFC 9848, DNS SVCB and HTTPS records RFC 9460, TLS 1.3 RFC 8446.

Projects can set a post-quantum TLS policy for traffic terminated at the edge.

This gives a project one cryptographic baseline even when tunnels are created by different CLIs, SDKs, or backend services. Instead of expecting every caller to request the same groups, the edge applies that posture centrally.

Two modes are available: preferred and required. preferred prioritizes hybrid post-quantum groups while keeping classical fallback groups available. required accepts only hybrid groups and enforces TLS 1.3 at runtime. An additional option limits selection to the NIST and FIPS-oriented P-256 and P-384 hybrid families.

The setting applies to terminated TLS surfaces for the project, including HTTPS, TLS, and QUIC endpoints. TLS passthrough remains excluded because the edge does not terminate the handshake. Community Edition deployments do not enforce this policy.

For the runtime policy model, refer to Access Policies.

References:

TLS 1.3 RFC 8446.

Tunnel access can be restricted directly on credentials and short-lived tokens.

Tunnel resources let a token apply to every tunnel project, selected workspaces, selected projects, or advanced JSON rules. Advanced resources can limit tunnel creation, tunnel discovery, tunnel connections, and HTTP request paths.

This is designed for backend delegation. A backend can keep an application credential, then issue a one-minute token to a remote device that can create HTTP tunnels for one project without receiving account-wide API access or connection rights.

Tunnel resources and operation-level tunnel scopes are available from the Dashboard and API on all managed plans. Advanced JSON uses explicit AND and OR objects so resource composition is visible in the stored JSON. Community Edition deployments do not enforce this model.

For the full model and examples, refer to Fine-grained tokens.

Project-wide settings are available for rstream tunnels.

Project settings add a policy layer above individual tunnel requests, so a project can keep the same access model even when tunnels are created by different credentials, SDKs, or backend services.

Project settings include:

• public access policy
• trusted IPs
• GeoIP restrictions
• minimum TLS version

Public access can allow public tunnels, require rstream Auth or token auth, or reject public tunnels entirely. Minimum TLS version applies to all published tunnels, whatever the protocol.

Trusted IPs and GeoIP restrictions act as project-level bounds. When a tunnel request also specifies values, the engine keeps only the overlap with the project policy and rejects the tunnel when no overlap exists.

Public access policy and minimum TLS version are available on Basic, Pro, and Enterprise projects. Trusted IPs and GeoIP restrictions require Pro or Enterprise. Project settings are not enforced on Community Edition deployments.

For the access policy model behind these settings, refer to Access Policies.

Managed STUN and TURN is available directly from rstream tunnels.

If a tunnel project already publishes the signaling API or WebSocket endpoint for a WebRTC application, the same project can issue TURN credentials and use the hosted relay service for ICE fallback. That removes the usual split between publishing signaling and operating a separate STUN/TURN stack.

The hosted service accepts STUN binding requests over UDP and TCP on IPv4 and IPv6. TURN UDP relay allocations are available over UDP, TCP, TLS, and DTLS on IPv4 and IPv6. TURN TCP relay allocations are currently available over TCP and TLS on IPv6.

You can issue TURN credentials through the platform API, through the Go SDK, or through local derivation inside an existing backend.

Managed STUN and TURN is included on hosted plans at no additional cost. Relay usage is metered independently from regular rstream tunnels bandwidth; quota varies by plan. Community Edition deployments do not include managed STUN/TURN.

The dashboard now surfaces TURN alongside the existing tunnel views. The project usage page keeps TURN bandwidth separate for the current billing period, and the dedicated TURN page adds connection details, credential issuance, monthly usage, and 30-day operational breakdowns for relay traffic, concurrency, transports, allocation types, address families, and client countries.

For protocol details, issuance flows, hosted limits, and dashboard behavior, refer to STUN and TURN.

References:

STUN RFC 8489, TURN RFC 8656, ICE RFC 8445.

rstream UI adds an interactive operator view to the CLI for live project inventory and WebTTY access. WebTTY servers, tunnels, and clients now appear in a single screen, with live updates streamed from the signaling API.

You can inspect a target, switch between summary and JSON views, and open an embedded WebTTY session without leaving the CLI.

This is the path for sessions where discovery and access happen together. If a machine is only reachable through outbound connectivity, rstream UI removes the context switch between finding the target and opening it. rstream webtty list remains available when plain inventory output is enough.

rstream UI is available in rstream CLI 1.9.0 and later.

For the full remote-access workflow, refer to Access Remote Machines with rstream WebTTY.