The short version is on the landing page. This is the long one — how the agent connects, how the browser authenticates, how a direct link is opened, and what flows on top of it.
Host boot → Signaling → SRP authentication → Encrypted data flow → WebRTC establishment
Each piece of the system has a narrow job. The whole only works because every part keeps to its role.
The agent runs as your user on Linux or macOS. It opens an outbound, TLS-protected WebSocket to the relay. Nothing listens on your network. When a browser asks for a session, the agent spawns a PTY (an interactive shell) bound to that browser.
The relay pairs your agent and your browser by their identifiers and relays signaling messages. After authentication and key derivation, the relay either forwards opaque encrypted bytes or steps out of the path entirely once a direct connection is established.
The web client lives in your workspace. It speaks the same binary protocol as the native CLI, handles a full xterm.js terminal, file manager, and code editor. No browser extension or native helper is needed.
After SRP-6a authentication, both sides derive an AES-256-SIV key via HKDF-SHA256. From that point on, every terminal byte, every file chunk, and every editor action is encrypted between the agent and the browser — independent of the transport in use.
In parallel with the active session, the browser initiates a WebRTC negotiation through the relay. Once the data channel opens, traffic flows directly between the two peers — the relay is no longer in the data path.
If direct P2P can't get through — symmetric NAT, strict firewall rules — traffic moves to a TURN-assisted WebRTC path. If even that's blocked, the session keeps running over the WebSocket relay. End-to-end encryption is preserved at every layer; sessions stay reliable across any network.
The host, the relay, and the browser each own a narrow surface. They all speak the same wire protocol so they can move data cleanly between transports.
The same binary format carries everything: authentication, shell I/O, file transfers, WebRTC signaling, control commands.
A length-prefixed JSON header followed by an optional binary payload. Each message has a type (auth, data, file, cmd, webrtc, encrypted, ...) and travels over the same connection — whether that connection is WebSocket or a WebRTC data channel.
Multiple concurrent PTY sessions share a single transport connection. The signaling server assigns each browser a session identifier, and the agent routes encrypted traffic to the correct PTY based on it. No extra sockets, no extra overhead.
Files move in 64 KB chunks — small enough to be safe on WebRTC data channels and WebSocket frames. A running SHA-256 hash is built during transfer and verified on the receiver before the file is committed.
Every encrypted packet carries a monotonic counter, strictly increasing per session and per direction. Replays, reorders, and tampering are detected and rejected before the payload is processed.
Sessions stay reliable across any network by falling back through three layers in order. End-to-end encryption is preserved at every layer — the relay never sees plaintext.
Preferred · Free
Pro · Counts toward quota
Last resort · Durability guarantee
One command on the machine you want to reach. Pair it from your browser. You're done.