Recipes — one-click installs

Install and harden software on your server in one click with Servor recipes — verified playbooks that check the box, adapt, and run step by step with live progress.

A recipe is a one-click, verified install. Pick "Install nginx", "Install PostgreSQL", "Harden SSH" or "Install Docker", and Servor does it for you on the server — checking the current state first, adapting to what it finds, and running each step with its own verification. You watch it happen as a live checklist, not a chat.

Recipes are available on every plan, including Free. They are powered by a lightweight model on Servor's side and are gated by a monthly quota per plan — they do not spend your AI credits.

Run a recipe

Open a connected server

Go to Servers and select the machine. It must be connected — if it's unreachable, repair the agent first. Your vault must be unlocked; see Unlock your vault.

Open the Recipes tab

Pick a recipe from the catalogue — grouped by category, each with its risk level.

Fill in any settings and run

Some recipes ask for a setting (a domain, a port). Then press Run — no prompt to write.

Watch the checklist

Servor first runs a reconnaissance pass (is it already installed? is there a config already? where?), then works through the steps, ticking each one off and verifying it. Under each task, the commands actually being run show live (expanded while running, collapsed once done) — you see exactly what happens. A long step shows a timer, and a destructive step pauses for your confirmation.

Reconnaissance first — it adapts to your box

A real server is messy: something might already be installed, a config might already exist, paths might not be where the manual says. A recipe never runs blind. It starts by inspecting the actual state and adapts — if the software is already there and healthy it verifies and skips, an existing config is left untouched, non-standard paths are detected. That is why a recipe is reliable where a fixed script would break.

Tuned to your server's OS

The catalog adjusts to the detected operating system. On a Linux server you see the Linux recipes (packages via apt/dnf, systemd services). On Windows (winget/Chocolatey, PowerShell, Windows services) and macOS (Homebrew) you see the matching recipes. A recipe that does not apply to your OS simply does not show up — you can't accidentally run a Linux command on a Windows box. The Linux catalog is the largest; the Windows and macOS sets keep growing.

Your own recipes

The official catalog will never cover your in-house stack. An admin can write the team's own recipes from Settings › Recipes: they then appear in the catalog on every server of the team, alongside the official ones, and run exactly the same way.

A recipe is written as JSON — not a form, because a playbook is nested (recon probes, ordered steps, per-step verification, variables, guardrails) and a text editor handles that better than a stack of fields. The editor validates against the exact schema the API enforces: errors show with their path (steps.0.command), and what passes in the browser is what the API accepts.

{
  "slug": "install-redis",
  "name": "Install Redis",
  "category": "cache",
  "targetOs": ["debian", "ubuntu"],
  "riskLevel": "caution",
  "recon": [{ "command": "command -v redis-server", "looksFor": "already installed?" }],
  "steps": [
    {
      "id": "install",
      "title": "Install the package",
      "command": "apt-get install -y redis-server",
      "riskLevel": "caution",
      "verify": { "command": "systemctl is-active redis-server", "expect": "active" }
    }
  ],
  "guardrails": "Never overwrite an existing redis.conf without saying so."
}

Four rules make a recipe behave like the official ones: recon first (read-only), idempotence (a second run breaks nothing), one concrete verification per step, and any destructive step marked "destructive": true so it pauses for your confirmation.

Writing, editing and deleting a team recipe requires the admin role — a member can run one, not define it. Deleting a recipe does not delete the history of its past runs.

Run history

The Recipes tab has a Catalog / History toggle. The history lists every recipe already launched on this server — name, status (success, failed, running…), date and step count — so you can tell at a glance what's already been installed and whether a run failed.

Recipes respect every safety rule

Every command is signed by your browser and run through the agent — same zero-knowledge path as the copilot. Servor's servers never execute anything.
A destructive step (firewall change, SSH hardening, a swap file) pauses for your explicit confirmation before it runs.
Blacklisted commands stay blocked.
Only members, admins and owners can run recipes — viewers can't run commands. See Roles and permissions.

Quota

Each plan includes a number of recipe runs per month (Free includes a couple; paid plans include more, up to unlimited). The count resets with your billing period. When you run out, upgrade or wait for the reset — everything else on the server keeps working.