Skip to content

    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.

    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 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 to run something against one host in about ten minutes
    • Core concepts for the seven nouns everything else assumes