WebTTY FAQ

How is WebTTY different from SSH?

SSH is a protocol and ecosystem for remote shell access. WebTTY is an rstream remote-terminal product built around outbound connectivity, browser access, CLI access, project permissions, optional terminal E2E with endpoint authentication, managed recordings, and live collaboration.

Use SSH when the workflow depends on SSH-native behavior such as ssh_config, agent forwarding, scp, sftp, or existing bastions. Use WebTTY when the machine opts into rstream access without an inbound shell service, or when browser terminal access, recordings, live collaboration, or workspace-managed encryption matter.

For the operating model, start with WebTTY. For a practical remote-machine walkthrough, see Access Remote Machines with rstream WebTTY.

Should I use a lightweight WebTTY tunnel or a registered server?

Use a lightweight WebTTY tunnel for temporary access, demos, development machines, short-lived agent work, and support sessions that do not need persistent inventory or managed recordings. The server is discovered through live tunnel inventory and disappears when the process stops.

Use a registered WebTTY server when the machine must remain visible while offline, when policy and labels are durable product state, when managed session recordings are required, when users need live attach or control requests, or when Enterprise workspace-managed E2E is required.

The two workflows are documented in Lightweight WebTTY Tunnels and Registered Servers.

Can rstream read terminal data?

Without WebTTY end-to-end encryption, terminal data is visible where the engine handles plaintext according to the selected runtime and recording policy.

With WebTTY E2E, terminal stdin, stdout, and stderr are encrypted at the payload layer. The client verifies the WebTTY server endpoint identity, and the E2E server verifies a signed client proof before it starts a process. The engine can still parse protocol metadata, route sessions, enforce policy, and store encrypted recordings, but it cannot decrypt terminal bytes without trusted client key material.

The detailed model is documented in End-to-End Encryption and Encryption Model.

How can E2E sessions be recorded?

Recording does not require plaintext terminal bytes. Managed recordings store ordered session events. For E2E sessions, terminal payloads are stored as ciphertext plus crypto metadata. Trusted browsers or trusted devices decrypt locally when an authorized user exports or replays a recording and that client has the session key grant needed for that session.

Session export and replay behavior are documented in Session Recordings.

Why is the filesystem sidecar disabled with E2E?

The filesystem sidecar is a separate file API next to command execution. It can list, read, upload, download, or write files under a configured root. WebTTY E2E protects terminal payloads, not a separate WebDAV file surface. Running both together would make the product look encrypted while leaving file access on a different security model.

Use the sidecar for non-E2E workflows where file access is intentional. For encrypted terminal workflows, use a separate file path with its own authorization and encryption model.

Do users pass E2E flags every time?

Not for registered servers. The client resolves the registered server policy at runtime. If the server requires E2E, the CLI, rstream ui, browser client, or SDK integration must satisfy that policy before terminal content is sent.

Explicit flags are still useful for fail-closed automation. For example, --e2e tells the CLI to fail if the resolved server is not encrypted.

Is browser trust the same as CLI trust?

Trusted browsers and trusted devices are separate cryptographic clients. A browser can open protected Dashboard flows when it holds trusted browser key material. A CLI, agent, or service can open protected CLI flows when it is enrolled as a trusted workspace device.

This separation matters for WebTTY. A user may have project permission to open a terminal but still fail to decrypt a workspace-managed E2E session from an untrusted browser or CLI device. See Trusted Browsers and Devices.

What if a trusted browser is lost?

Losing one trusted browser does not break a workspace if another trusted browser, trusted device, or the current Recovery Kit is available. Revoke the lost browser, then enroll a replacement browser or device from an existing trusted access path.

If every trusted browser, every trusted device, and the current Recovery Kit are lost, workspace-managed WebTTY recordings cannot be decrypted from server-side data alone. That is the intended zero-trust failure mode. Recovery behavior is covered in Recovery Kit.

Can sessions be shared?

Lightweight browser sessions can expose a browser-facing WebTTY endpoint when the server is published and the caller has the required rstream authorization. That is useful for short-lived demo and support flows.

Registered WebTTY servers use managed live collaboration instead. Operators attach as spectators or request control of an active session according to project permissions and the session controller approval flow. See Live Collaboration.