How Shely works

A keystroke leaves your browser and reaches your server through a small, well-defined path. There is no plugin and no local agent in the way.

From keystroke to server

Three hops, each doing one job.

  1. Your browser

    You open a saved connection. xterm.js draws the terminal in the page and opens a WebSocket to the gateway using the shely.terminal.v1 subprotocol. What you type goes up that connection, and what the server sends comes back down it.

  2. The API and the gateway

    A REST API handles your account, synced hosts, teams and the assistant. A separate, stateful WebSocket SSH gateway holds the live session and streams it in both directions. Splitting the stateless API from the stateful gateway is what lets reconnects resume a session rather than restart it.

  3. Your server

    The gateway speaks SSH to the host you named and relays the session back to your browser. Your server sees an SSH connection, the way it always has.

The stack behind it

Familiar, boring-in-a-good-way pieces doing predictable work.

Backend

A stateless TypeScript API (Node.js and Fastify) with PostgreSQL for durable data and Redis to coordinate the moving parts, plus a separate stateful WebSocket SSH gateway.

Web

The console at console.shely.app is a Next.js and React app that draws the terminal with xterm.js. This site is a separate static Next.js site, so signing in and everything after it happens in the console, not here.

Native clients

There is a native Swift app for Mac, iPhone and iPad and a Tauri 2 desktop app for Windows. They sign in to the same account as the console. Their SSH and SFTP connections go straight from your device to your server, without the gateway.