Run commands
Run foreground and background commands on your servers in Servor, search the full command history, and understand blocked dangerous commands.
Servor lets you run commands on any connected server without opening a full terminal — in the foreground for quick tasks or in the background for long ones — and keeps every command in a searchable history. This page covers all three, plus what happens with blocked commands and read-only viewers.
Unlock your vault to run anything
Running commands needs an unlocked vault. Enter your passphrase if you see the unlock screen — Unlock your vault. Read-only viewers can browse history but can't run commands (see below).
Foreground commands
Foreground commands run and return their output to you right away — ideal for quick,
finite tasks like systemctl status nginx, df -h, or git pull.
Open the server
In Servers, open a connected server. If it's unreachable, commands won't run until the agent is back.
Type your command
Enter the command in the run box and send it. You'll see the output as it comes back, along with the exit status when it finishes.
Review the result
Output and exit code are captured and added to the command history automatically.
Need an interactive session?
The run box is best for one-shot commands. For an interactive shell — editing files, running a TUI, watching live output — use the web terminal instead.
Background commands
Some tasks take minutes or hours: a backup, a package upgrade, a long import. Run these in the background so they keep going even if you close the tab or your connection drops.
- Choose to run in the background when you send the command.
- The task keeps running on the server independently of your browser.
- Its output and final status are recorded in the history, so you can check how it went later.
This is the reliable way to run anything long — unlike a terminal session, a background command doesn't die when your session ends.
Pinning the commands you keep retyping
Above the runner, the Pin button saves the current command as a shortcut for this server. It then shows up as a chip: one click puts it back in the field, ready to be read over and launched.
Pins are local to your browser and specific to each server. This is not team configuration: it is the note of the two or three lines you keep retyping on this machine. Pinning grants nothing — the chip fills a field, and everything after that is the same signed path as always.
Command history
Every command you run — foreground, background, or typed in the web terminal — is recorded per server, with who ran it, when, the output, and the exit status.
Look under the runner
On the Terminal tab, the history sits beside the runner and shows only what you launched there: commands from the copilot, recipes, the terminal and scheduled tasks do not crowd it.
Open the full history
The See the full history link lists every source together — copilot, recipes, terminal, cron — newest first.
Search and filter
Use the search box to find a past command by its text or output. This is the fastest way to answer "what did we run last time?" or "when did this last fail?"
Inspect a run
Open any entry to see its full output and exit status.
History is a shared record
Command history is visible to your team, including read-only viewers. It doubles as an audit trail of what was run on each server.
Blocked commands
Servor enforces a shared blacklist of dangerous commands to protect you and your
team from catastrophic mistakes. If a command matches the blacklist — the classic
example being rm -rf / — it is blocked before it runs, whether you send it from
the run box, the web terminal, or through the AI copilot.
The same protection applies everywhere commands can be executed, so there's no way to sneak a blocked command through a different entry point.
Pipelines are allowed: df -h | grep /dev, systemctl status nginx && journalctl -u nginx -n 50, a substitution — write the command the way you would type it. The only
constraint on shape is one line per run: a multi-line script belongs in a file, which
the explorer can write. The blacklist is matched against the whole line, so nothing hides
behind an &&.
Blocking isn't a safety net for everything
The blacklist catches known-catastrophic patterns, not every risky command. You're still responsible for what you run — double-check destructive operations, and prefer background commands with clear, reviewable text.
One command across several servers
From Servers › Run, the same command goes out to several machines. Pick targets one by one, or a whole section at a time: a section heading ticks everything in it, which makes “across all of prod” as quick to ask for as it is to say.
One signature per server, not one for all of them
Your browser issues as many signatures as there are machines, each covering its own server's id. A grant issued for one machine is therefore worth nothing against another, and Servor still cannot execute anything on its own — including here, where other fleet tools broadcast a command in the clear.
Runs are sequential, not parallel. A command going out across a whole fleet is exactly where a mistake multiplies: results arrive in an order you can follow, and you can stop after the third failure rather than the fortieth.
Viewers are read-only
If your role is viewer, you can open a server and browse its command history, but you cannot run commands — the run box and terminal are disabled. This is by design: viewers have read-only access everywhere. To run commands you need at least the member role. See roles and permissions.