Architecture And Performance Guide

Back

Direct SSH Mode

You click a saved remote connection and the app server itself opens SSH using ssh2.

[Browser UI]
    |
    | (1) WebSocket frames
    v
[WebSSH Server]
    |
    | (2) SSH transport (ssh2)
    v
[Remote Server]
    |
    v
[Remote Shell]
Hop view:
UI -> WebSSH -> Remote

Local Terminal Mode

You open the shared local tab and run commands in a local PTY (node-pty). If you then type ssh ..., SSH happens inside that local shell.

[Browser UI]
    |
    | (1) WebSocket frames
    v
[WebSSH Server]
    |
    | (2) Local PTY session
    v
[Local Shell on Host]
    |
    | (3) optional: ssh user@host
    v
[Remote Server]
Hop views:
Local-only: UI -> WebSSH -> Local PTY
Via SSH from local: UI -> WebSSH -> Local PTY -> Remote

Why “Local” Can Feel Faster

If you run only local commands, there is no remote network latency. That typically feels very fast.

Local command latency ~= UI rendering + localhost WebSocket + local process scheduling

Remote SSH latency ~= above + remote network RTT + remote server response

When Both Feel Similar

  • You are running remote commands in both paths.
  • Terminal renderer and WebSocket layer are shared.
  • Remote command time dominates over UI transport time.
Same remote target + same command
=> often similar perceived speed
(difference is mostly where SSH is initiated)

Quick A/B Test Plan

  1. Open a direct SSH tab to your target server.
  2. Open local, then run the same ssh user@host.
  3. Run identical commands in both tabs: pwd, ls -la, git status.
  4. Compare first-byte response feel and scroll smoothness.