Recipes are your fleet’s reusable playbook. Write a shell script once, parameterise it, and run it against one server or a whole tag. Every run lands in a structured execution history with output, exit code, and duration. If you want to trigger it from your terminal instead of the web UI, expose it to the Server CLI with one field.

What you see

Open Recipes / Scripts in the sidebar. The index page shows every recipe you own:

• Name, description, tags.
• Runtime (bash by default; other interpreters as your fleet supports them).
• CLI tag if it’s been exposed to the Server CLI.
• Last-run timestamp and outcome.
• A Run button and a menu for edit / delete.

Below the list, KPI cards summarise total recipes, last-24 h executions, success rate, and average duration.

The editor

Creating or editing a recipe gives you:

• Name and description — what shows up in the UI and CLI listing.
• Script body — the code that runs on the target server. Bash is the default; any interpreter available on the target can be used via a shebang.
• Parameters — typed inputs (string, integer, boolean, select, secret) that get injected as environment variables at run time. Each parameter has a label, default, and help text.
• Timeout — hard kill after N seconds.
• CLI Tag / CLI Group / CLI Description — expose the recipe to the Server CLI so it becomes hostatlas <group> <tag> inside an SSH session.
• Tags — free-form labels used for filtering and for grouping in bulk runs.

AI assistance

Three AI helpers sit inside the editor:

• Generate — describe what you want (“nightly logrotate for /var/log/nginx keeping 14 days”) and the assistant drafts the script and parameters.
• Optimize — rewrite the current script for clarity, safety (set -euo pipefail), and idempotency.
• Extract metadata — pastes in a raw script and the assistant fills in name, description, parameters, and CLI tag suggestions.

You review and edit the result before saving — nothing is written without a human click.

What you can do

• Run on a single server — pick a target, fill in parameters, submit. A modal streams the output live; you can abort mid-run.
• Bulk run — pick multiple servers (or a tag), fill parameters once, launch. The bulk-run screen shows KPI cards (queued / running / succeeded / failed) plus a per-server table you can drill into.
• Abort a running execution — the agent receives a cancel signal.
• Open the execution history — every past run with target, user, parameters, exit code, and stdout / stderr. Failed runs are surfaced first.

How it works

• A run is dispatched to the target server’s agent as a queued command. The agent writes the script to a temp file, injects parameter values as environment variables, executes it under the configured user, and streams stdout / stderr back.
• The web UI polls the execution record and shows output as it arrives. Closing the tab does not abort the run — it continues on the server.
• Bulk runs fan out one queued command per server; each is independent so a slow host does not hold up the others.
• Exposure to the Server CLI is opt-in. When a recipe has a CLI tag, the agent picks it up on its next configuration sync and it appears in hostatlas help on the box.

Tip

Anything you run more than twice, put in a recipe. You get audit, parameters, timeouts, and CLI access “for free” — plus a Recovery rule or Automation can invoke it later without any glue.

Related

• Server CLI — surface recipes as first-class terminal commands on each host.
• Automations — trigger recipes on a schedule, webhook, or alert.
• Recovery rules — run a recipe when a specific alert fires.