Run multi-step plans on your servers over SSH, with nothing installed on them.

A plan is an ordered list of steps that run against the hosts you name. Draft it by hand, from a plain request or from a git repository, preview it on every host, and run it now or on a schedule. This is the runbook automation your team already wants. The approval and the record come with it.

What it automates

The everyday work on a server, written down once and run the same way.

The tools are the ones in the tool catalog. Anything else is a script a step uploads and runs.

Plans over SSH: A plan is an ordered list of steps, each calling a tool or a script against named hosts. Opafra connects over ordinary SSH. The host needs one line in authorized_keys and nothing running on it.
Configuration management: Edit a file or deploy a template on many servers at once. Each host shows its own diff first, and every revision of the template is kept, with rollback.
Ansible playbooks as steps: Keep the playbooks you trust and run them as a step in a plan, next to the tools and scripts around them.
Reusable modules: When the same four steps appear in a third plan, make them a module with parameters and declared outputs. Fixing the module fixes every plan that calls it.
Schedules: Run a plan on a cron schedule with overlap protection, retries and dependencies between schedules. A nightly dry run of a plan that should not change anything is drift detection.
Git sync: Point Opafra at a repository and it imports plans, scripts and templates from it, one way. A synced plan is read-only in the builder, so a change goes through a pull request.
Discovery: Discover servers from Terraform, Kubernetes or a custom endpoint, preview what would change in inventory, then apply it.

Drafted by the AI composer

Describe the outcome in plain language. Get a plan of real steps back.

The composer sees your inventory, your environments and the tool catalog, and drafts a plan you can read, edit and dry run like any other. It stays a draft until you keep it, and it never runs anything.

Fig. 1, the draft the composer returned for @alex's request

Plans /Patch nginx across prod

Draft

Request

@alex

14:28:31

Patch nginx across prod and keep TLS 1.3 only.

Drafted by the composer

14:28:55

4 steps, 3 hosts, environment prod derived from the targets

1Back up current configfile.backupreads
2Upgrade nginx to 1.25.3apt.upgradechanges
3Write nginx.conf and reloadfile.templatechanges
4Verify TLS on :443http.probereads

Targetsweb-01web-02web-03

Sent to the model: your request, host and group names, and the names of scripts and templates.

Never sent: credentials, secret values, script bodies, host output.

The composer cannot run anything.

Previewed on each host

A dry run connects to every target and reports what would happen there.

Hosts disagree, and the difference shows before the change and not in the middle of it. A step with a read-only check reports would create, would change or no change. Any other step shows the exact text that would run.

Fig. 2, dry run of #4f2a, revision 7, on 3 hosts

Dry run #4f2a, revision 7

14:29:40Passed on 3 hosts

What the dry run found on each host
Host	Changes	Destructive	Time
web-01	4	0	810 ms
web-02, diff shown	4	0	790 ms
web-03	4	0	840 ms
Total	12	0
Since the last run	+2	0
ssl_session_tickets added

Diffweb-02

/etc/nginx/nginx.conf+3/−2

 --- a/etc/nginx/nginx.conf
 +++ b/etc/nginx/nginx.conf
 @@ -1,7 +1,7 @@
  user  www-data;
−worker_processes  4;
+worker_processes  auto;
  pid /run/nginx.pid;
 @@ -31,6 +31,7 @@
      ssl_prefer_server_ciphers on;
−    ssl_protocols TLSv1.2;
+    ssl_protocols TLSv1.3;
+    ssl_session_tickets off;

Fleet patch campaign

Patch a whole fleet in waves, and stop when failures pass the threshold.

A campaign runs one plan across the fleet with rolling execution: a wave of hosts at a time, with a failure threshold you set. The change control page covers the record of what was patched and what was skipped.

Waves: Hosts patch in groups of the size you choose, one wave after the next, so a bad patch meets a few hosts first and not the whole fleet.
A failure threshold: Set how many failures the campaign accepts. When failures pass the threshold it stops before the next wave starts.
Per host, the outcome: The record reads patched, failed or skipped for each host, with the reason for any host left out.

What Opafra adds

Automation that answers who ran it, and on whose approval.

Both follow the work. See the change control use case and the change record on the evidence page.

The approval: An environment can require approval, and then every run that touches it waits for a named person who holds access to it. The approval covers one exact revision, so editing the plan afterwards voids it.
The record: Who asked, what was drafted and by what, who approved, what each step did on each host. It stays in the append-only audit log after the plan is edited, and the log exports as CSV or NDJSON.

Run your first plan on your own hosts.

Tell us what you run and what you do by hand today. You get a demo and your price in writing within one business day, with no call.

Get a demo