← Engineering blog

An interactive shell has a different lifetime

A command over HTTP has a result and a short timeout. An interactive shell needs a connection, terminal dimensions, and a way to survive a dropped browser tab. Mainbrella exposes both forms of access, but keeps them tied to the same container generation and session limits.

Reconnect to the shell

The dashboard’s browser terminal uses xterm.js and a WebSocket authenticated with the browser’s HttpOnly session cookie and a trusted Origin. An API key does not authenticate that connection. The request includes the selected container’s creation timestamp and terminal dimensions.

The shell lives in the fixed tmux session main. Closing the panel detaches the client. A reload can reconnect while that generation is alive, and the browser client retries an abnormal disconnect up to five times with exponential backoff. A clean exit does not reconnect.

This reconnect behavior does not persist a workspace after stop. If polling shows that the container disappeared or changed generation, the client closes the terminal. The shell’s files remain temporary.

Reach it from a local terminal

SSH access goes through ssh.mainbrella.com using cloudflared on the user’s computer. The dashboard or POST /containers/ssh returns a command for the selected running container. The container does not need a public IP address, and the user does not need a Mainbrella CLI.

The returned command contains a credential. It belongs in the user’s terminal, not a repository, shared transcript, or diagnostic log. Its token lasts at most 15 minutes or until the hard container deadline, whichever comes first. Stopping or recreating the container invalidates the token.

Activity is not an unlimited extension

Terminal input and output renew the idle lease. Requesting an SSH token and reading container status do not. Neither activity nor reconnection extends the independent hard deadline. An agent cannot keep a one-hour Builder session alive indefinitely by sending periodic commands.

There are four combined browser and SSH terminal connections per container and ten live SSH tokens per account. HTTP commands have their own concurrent-operation pool. These are distinct limits, so a client should report which operation failed rather than treating every capacity error as a full account.

Use HTTP execution for bounded foreground commands and structured stdout, stderr, and exit status. Use SSH or the browser terminal when the work needs interaction. Both still require exporting any result that must outlive the container.

Client implementation: browser terminal source. Current connection and session bounds: Limits.