# What Opafra is

Opafra runs multi-step operations across your servers over SSH, with a preview before the change, an approval where you want one, and a permanent record.

Source: https://opafra.com/docs/what-is-opafra

---

Opafra runs multi-step operations across your servers over SSH. You describe the work
once as a **plan**, target it at an **environment**, and every run is previewed,
optionally approved, and permanently recorded.

Nothing is installed on the servers.

## What it gives you

**The work is written down.** A plan is an ordered list of steps, each calling a tool
against a set of targets. It can be written by hand, drafted from a description, or synced
from a git repository.

**The change is previewed.** A [dry run](/docs/running/dry-run) connects to every host and
reports what would happen there, per host, so the differences between machines surface
before the change rather than during it.

**The decision has an owner.** An environment can require approval, and then every run
touching it waits for a named person, against a known plan revision.

**What happened is on the record.** Who asked, what was drafted, who approved it, what
each step did on each host. Permanently, and it survives the plan being edited.

## Three properties worth knowing early

Every other page assumes these.

**It is agentless.** Ordinary SSH, one line in `authorized_keys`, nothing running on the
host. Adopting it costs a line; removing it costs deleting one.

**Dry run is per host and declares its confidence.** Tools that support a read-only check
report `would create`, `would change` or `no change` against the live host. Everything
else is shown as the exact resolved text rather than predicted. You are always told which
kind of answer you are looking at.

**The approval gate belongs to the environment, not the plan.** Marking `production`
protected gates every plan that touches it, including plans written later and including
one that names a production host directly rather than the environment.

## What it is not

Worth saying plainly:

- **Not a monitoring system.** It acts when you run a plan; it does not watch your hosts.
- **Not a configuration-management daemon.** There is no agent converging a host toward a
  desired state. A run happens when it is started.
- **Not a CI system.** It runs operations against servers, not builds against code, though
  a CI job can start a run.
- **Not able to reach an offline host.** There is nothing on the host to queue work. That
  is the trade-off agentless makes.

## Next steps

- [Quickstart](/docs/quickstart) to run something against one host in about ten minutes
- [Core concepts](/docs/concepts) for the seven nouns everything else assumes