SERVORdocs
fr

Use the web terminal

Open a live shell to any server in your browser with Servor's web terminal — copy/paste, keyboard shortcuts and instant reconnect, no SSH client required.

The web terminal gives you a live shell to any connected server right in your browser — no SSH client, no keys to manage. This page covers opening it, copy and paste, keyboard shortcuts, and reconnecting after a drop.

Unlock your vault first

The terminal runs real commands, so it needs an unlocked vault. If you see the unlock screen, enter your passphrase — see Unlock your vault. Read-only viewers can't open the terminal; they can still browse command history.

Open the terminal

Pick a connected server

In Servers, open a server showing a green connected status. If it's unreachable, the terminal won't open until the agent is back.

Open the Terminal tab

Click Terminal on the server page. A live shell session starts on the machine — you're dropped into a prompt just like a local SSH session.

Start typing

Run commands as you normally would. Everything you run is also recorded in the server's searchable command history.

Copy and paste

The terminal supports copy and paste so you can move commands and output around freely:

  • Copy — select text in the terminal; use your usual copy shortcut (Ctrl/Cmd + C). Because Ctrl + C also sends an interrupt to the running program, copy works on the current text selection — if nothing is selected, Ctrl + C interrupts instead.
  • Paste — Ctrl/Cmd + V pastes clipboard contents at the prompt. You can paste multi-line commands.

Check what you paste

Pasting multiple lines can execute each line immediately. Review multi-line pastes before sending, especially anything destructive. Servor still blocks known dangerous commands — see Run commands.

Terminal toolbar

The terminal header carries a few conveniences, none of which touch the running shell:

  • Search (Ctrl/Cmd + Shift + F) — a search bar over the scrollback with next/previous and match highlighting. Enter = next, Shift + Enter = previous, Esc closes it. Plain Ctrl + F still goes to the shell.
  • Copy scrollback — copies the whole buffer to your clipboard (ANSI codes stripped).
  • Clear — clears the screen (like Ctrl + L).
  • Preferences — font size and scrollback length, remembered in this browser.
  • Fullscreen — expand the terminal to fill the window.

You can also re-run any past command: on a row in the command history, the re-run button pre-fills the background-command runner with that command (it still runs signed, after your review — nothing executes on its own).

Keyboard shortcuts

The terminal behaves like a standard shell. The essentials:

ShortcutWhat it does
Ctrl + CInterrupt the running command (or copy the selection)
Ctrl + DSend end-of-file / exit the shell
Ctrl + LClear the screen
Ctrl/Cmd + VPaste at the prompt
Ctrl/Cmd + Shift + FSearch the scrollback
↑ / ↓Scroll through your shell command history
TabAutocomplete paths and commands

Standard shell editing shortcuts (Ctrl + A, Ctrl + E, Ctrl + U, Ctrl + R reverse-search, and so on) also work, since you're talking to the real shell on the server.

Reconnecting

If your connection drops — you close your laptop, switch networks, or the browser tab sleeps — the terminal session ends. To get back in:

Reopen the Terminal tab

Return to the server and open Terminal again. A fresh session starts.

If the server is unreachable, repair the agent

A dropped terminal usually just means your browser lost the session. But if the server itself shows unreachable, the agent is down — repair the agent first, then reopen the terminal.

Long-running tasks

A new terminal session is a new shell, so anything you started interactively stops when the session ends. For tasks that must survive disconnects, run them in the background instead of the foreground — see Run commands.

Pinning a terminal

A terminal normally lives on its server's page: leaving the page closes the view. The pin button, top-right of the terminal, moves it into a panel docked to the bottom-right of the screen — and that panel survives navigation. You can watch a build finish while reading the monitoring tab, or while working on another server.

Up to five servers can be pinned at once, each with its own tab. The panel folds away with the chevron without closing any session.

A pinned terminal leaves the server page, which then shows a short card with two buttons: show the panel, or detach to get the terminal back in place. This is not an arbitrary restriction — a shell session is identified per server, and two terminals open on the same host would attach to the same process, each resizing the other's window and splitting the keystrokes between them.

For the same reason, opening a pinned server's file explorer detaches it automatically: the explorer already carries a terminal of its own.

The shell keeps running

Pinning, detaching or switching tabs never kills the running process. The session stays open server-side for thirty minutes after a detach, and every view re-attaches to the shell that was already running rather than opening a new one. Reloading the page brings your pinned tabs back too.

Recording and replaying sessions

For audit or training, a team can have its terminal sessions recorded. An admin turns it on in Settings › Team › Team security; it is off by default, because recording what operators see is something a team decides, not something that happens to them.

Sessions then appear in the Terminal sessions panel on the server's page: who connected, when, from which address, and for how long. A recording replays in a real terminal — colours, cursor moves, a top redrawing itself — so what you watch is what the operator had in front of them, not an approximate transcript.

What is recorded, and what is not

Only the displayed output is captured, never keystrokes. That is deliberate: a password typed at a sudo prompt is not echoed by the terminal, so it is not recorded either. Each recording is encrypted with its own key, itself sealed with your team's key, and only admins can watch one — opening a replay is itself written to the audit log.

Two things worth knowing: a very noisy session (a tail -f left running) is truncated past a certain size and the replay says so; and even with recording off, the session list keeps filling up — knowing who opened a terminal and when is already an audit answer.

A session appears as soon as the first key is pressed, marked live for as long as the shell is alive. That is deliberate: closing the tab does not kill the shell, it detaches and keeps running — so the list also says who is on the machine right now.

Opening a terminal and closing it again without typing anything leaves no trace: there is no session to audit where nobody did anything, and a list full of empty openings is a list people stop reading.

When a session has nothing to replay, the list gives the reason rather than a flat "not recorded": Recording off (the team setting was off when the shell opened — turning it on does not retroactively capture a session already running), Recording (the shell is still alive), No output (nothing was ever printed), or Recording failed, which flags a genuine storage incident and shows the detail on hover.

See also