Skip to content
Sencai.docs

Browser terminal

The browser terminal gives you an interactive shell to a registered cloud instance directly from its page in the app, with no local SSH client and no separate credentials to manage. It’s a different connection path from the fleet agent’s own control connection (see Fleet agent), but it’s grouped with fleet capabilities because it serves the same goal: operating your infrastructure without juggling a pile of SSH keys.

Which plans include it

Section titled “Which plans include it”

The browser terminal is included from the Professional tier and up (not on Starter), bundled with just-in-time elevation. See Billing & plans for the full tier comparison.

Prerequisites

Section titled “Prerequisites”
  • The target machine must be registered in your organization as a cloud instance (see Provision & manage instances) - the terminal isn’t available for a host that’s only enrolled through the fleet agent without also being a registered instance.
  • Sencai needs a route to the instance’s SSH port and an account on it that the platform’s own key is authorized for. For an instance provisioned through Sencai this is normally part of setup; for an instance you imported, an admin can set explicit connection details on the instance record if the defaults don’t apply.

Opening a session

Section titled “Opening a session”
  1. Open the instance’s own detail page.
  2. Open its Terminal.
  3. A connection status indicator shows Connecting…, then Connected once the shell is live. If it fails, a Try again option is shown along with the reason.

The terminal resizes with your browser window, and closing the tab or clicking the close button ends the session cleanly.

How a session is authorized

Section titled “How a session is authorized”

Opening a terminal uses your own logged-in session - there’s no separate terminal password or key to manage. Sencai checks that you’re a member of the organization that owns the target instance before opening anything; if you aren’t, you get the same “not found” response you’d get for an instance that doesn’t exist at all, rather than a response that confirms the instance exists in someone else’s organization.

A few limits apply to every session:

  • Up to 3 concurrent terminal sessions per user
  • A session is closed automatically after 30 minutes of inactivity
  • Repeated connection attempts are rate-limited

Session recording and audit

Section titled “Session recording and audit”

The start of a session, its end, and each observed command boundary are recorded in your organization’s audit trail. By default, only the fact that a command boundary occurred is recorded (and its length) - not the command text itself. This is deliberate: a shell session can include a non-echoing prompt (a password typed at sudo, for example), and capturing raw keystrokes by default would risk writing a secret into a permanent, append-only audit record.

Known limitations

Section titled “Known limitations”
  • Host identity isn’t verified or pinned on first connection today - unlike a regular ssh client, which asks you to confirm a host’s fingerprint the first time you connect, the browser terminal doesn’t yet do the equivalent check.
  • The terminal only works for registered cloud instances reachable over SSH from the platform - it isn’t a general-purpose tunnel to any host running the fleet agent.
  • If you’re going to rely on the terminal during an incident, confirm it works with a test connection to a non-critical host beforehand, rather than trying it for the first time under pressure.

What’s next

Section titled “What’s next”