Why we built Servor around Plan, Execute, Verify

The original sin of infrastructure copilots

The first AI agents that touched infrastructure all worked the same way: you asked a question, they answered with a shell command to run. Seductive — and disastrous. One misread prompt and there goes rm -rf / on a production box. Not the moment you want to find out that your agent never grasped the difference between staging and prod.

Servor was built out of that frustration. The rule behind the whole architecture fits in three words: Plan, Execute, Verify. Never in another order.

1. Plan — say it before you do it

The Servor copilot has exactly one tool: run a command. No magic connectors, no hidden API. When you ask it to “update nginx on the three European servers”, the only thing it can do is propose command lines, one at a time, and wait.

Before anything runs, the interface shows you:

• the exact command, as it will be sent — not a paraphrase of it;
• the target server and the system user it will run as;
• the risk class assigned to that command: read-only, reversible change, or destructive operation;
• the approval mode currently in force, which you can change mid-session.

There are three modes. Ask: the copilot answers, analyses and explains, but never executes. Plan, the default: every command goes through your approval. Auto: the copilot keeps going and only interrupts you on a command classified as destructive.

When a sequence deserves to be frozen, it is frozen by a human, not by the model: that is what a runbook is — a reviewed, versioned, replayable series of commands. Servor ships 27 of them: nginx, Caddy, PostgreSQL, Redis, Docker, SSH hardening, fail2ban, UFW, WireGuard and the rest. A runbook is executable documentation; a copilot session is a conversation. Both have their place, but they are not the same object.

2. Execute — signed in the browser, verified on the machine

This is the least intuitive part of the architecture: Servor's servers are not the ones executing. The run_commandtool call is handed back to the browser, which classifies the risk, applies the mode's policy, gets your approval, then signs the command with an Ed25519 key derived from your vault key.

What that buys you, concretely:

1. the API relays the signed command verbatim — it cannot rewrite it without breaking the signature;
2. the agent installed on the target machine verifies the signature locally before running anything;
3. stdout, stderr, the exit code and the duration are captured and filed in one unified history, whatever the command's origin — manual, AI, runbook or terminal.

Everything goes through the agent, which opens an outbound connection to the control plane itself. No inbound port to open, and nothing resembling SSH driven from our servers: SSH is used for bootstrap only, long enough to install the agent.

The forbidden-command list: defence in depth

Even in Auto mode, some commands are refused no matter what you approve. Not by policy — by code: a lightweight parse inspects every command before it is relayed and rejects it if it matches a forbidden pattern. rm -rf /, raw writes to /dev/sd*, edits to /etc/passwd, /etc/shadow or /etc/sudoers, fork bombs. The check runs twice: once on the control plane, and again on the agent.

What Servor does not do — and why we say so

Servor takes no snapshots and restores nothing. There is no hidden automatic rollback behind a button. A destructive operation stays destructive: catching it is your backup strategy's job, not ours. We would rather write that down than let you assume a safety net that does not exist.

3. Verify — trust is the part you prove

The most neglected step, and the one that changes everything. Verify is what you should have done after every manual intervention but “forgot” because you were sure of yourself. The copilot has no ego about it: you ask it to prove the change landed, it runs a read-only command, and you read the output.

In practice, a verify looks like:

• a command that has to exit 0 — nginx -v piped into a grep for the version you expect;
• a systemctl is-active on the unit you just touched;
• a curl -sS -o /dev/null -w "%{http_code}" https://… against the public endpoint;
• a check on a generated file — that it exists, its size, its checksum.

And verification does not stop when the session ends. Servor's monitors — HTTP, TCP, ping, SSH, DNS, TLS certificate, disk space, process presence, custom script — keep watching, with configurable hysteresis so a single hiccup does not flip anything. That is the verify step that outlives the operator.

The audit ledger signs everything

Every command is written to the audit log, hash-chained to the entry before it. An UPDATE or a DELETE on a past entry? The append-only PostgreSQL trigger refuses. Six months later an auditor can export the chain and check that it still holds. The ledger is harder to corrupt than your operators.

What about latency?

Fair question: if you have to read, approve, execute and verify, you will never keep up with an incident in progress. The answer is Auto mode, with guardrails negotiated up front — guardrails that, unlike approval, cannot be switched off. And for routine work — installing a service, restarting a unit, renewing a certificate — the official runbooks do the job without anyone having to convince a language model first.

The goal is not to slow your operations down. It is to make carelessness cost clicks and show up in the log. Guardrails reduce risk; they do not remove it, and the operator remains responsible for what they approve.

Going further

If you want to see how this discipline coexists with a zero-knowledge architecture — where Servor operates on your servers without ever seeing your credentials in the clear — read our piece on the zero-knowledge implementation. If you would rather try it, create a Free account, add a throwaway server, and stay in Plan mode long enough to form an opinion.