Governed changes and access for your servers, and the record each use case leaves.
When a client sends a questionnaire, an auditor samples your servers or a regulator asks who had access, you need a record and not a recollection. Opafra runs the everyday work on your servers and writes that record while it happens. Each group below has its own page.
By use case
Six groups of work. Each one leaves a record.
The records are evidence for the points they answer, not a verdict that anyone meets them. See all four on the evidence page.
Infrastructure automation
- What Opafra does
- Multi-step plans over SSH with nothing installed on your hosts. The AI composer drafts a plan from a plain request, a dry run shows what each host will do, and schedules, git sync, Ansible playbooks and reusable modules keep it going.
- The record it leaves
- The approval and the record come with the work: who asked, what drafted it, who approved, what each step did.
Third-party and supplier access
- What Opafra does
- Access to a client server is requested with a reason, approved by a named person, limited to a window and ended without anyone remembering to undo it. Your client can be the one who approves.
- The record it leaves
- The access record: the request, the approver, the window, how it ended and every connection under it.
Privileged access and reviews
- What Opafra does
- Admin rights are granted for a window and end on their own. At the interval you set, the reviewer goes through everyone with access to an environment, keeps or removes each person, and signs.
- The record it leaves
- The signed review: who reviewed, when, and what changed.
Change control
- What Opafra does
- A change is previewed on each host and approved for one exact revision. Patching, with the reason a server was skipped, and certificate renewal run as scheduled changes through the same gate.
- The record it leaves
- The change record: the chain from request to outcome, the dry run per host, and the model named when the AI composer drafted it.
Backup and recovery evidence
- What Opafra does
- A scheduled plan restores the latest backup onto a scratch host, runs a smoke test and removes the copy.
- The record it leaves
- The restore record: the result and the time from the first step to the passing test, written each time the plan runs.
Audit and compliance
- What Opafra does
- Questionnaire answers keyed by question ID, evidence for each point of Regulation (EU) 2024/2690, and the samples for an ISO 27001 surveillance audit. See the answer pack and the evidence page.
- The record it leaves
- The same four records, attached to the answers and the samples they support.
Who it's for
The same work, seen from the team that does it.
- Hosting and managed hosting
- Stop redoing each client's server work by hand, and give each client the record. Read the page.
- Managed service providers
- Every client's Linux servers, run from shared plans, each change approved by that client. Read the page.
- DevOps consultancies and agencies
- Governed changes on every client estate, with the record each client can keep. Read the page.
- Platform and IT teams
- Production changes the whole team can run, each one dry-run, approved and recorded. Read the page.
- Financial services
- Fewer hours on server work and audit preparation, with every run tied to its change record. Read the page.
For engineers
The same tool runs the everyday work, so the record comes from work you already do.
A plan is a sequence of typed steps against named hosts. Every plan dry-runs first, waits for approval where an environment requires it, and lands in the audit log.
- Patching and upgrades
- Packages, kernels and services across a group of hosts, with a preview on each host and the approval before anything changes.
- Config changes
- Edit a file or a template on many servers at once, see the diff on each host first, and keep every revision.
- Runbooks
- What lives in one person's shell history becomes a plan the rest of the team can run. Access expires on its own, so someone leaving is removed rather than every key rotated.
- Moving from other tools
- Bring what you have from AWX, Rundeck or Chef. The Chef migration guide maps recipes to plans.
Plan library
21 plans to start from. Run them as they are, or as the start of yours.
Adapt one to your hosts, put it on a schedule, chain it after another, or describe a new one and let the AI composer draft it against your inventory.
- Deployment
- Getting software onto hosts the same way every time, with the rollback defined before the rollout.
- Application deployment: web apps and APIs, with the proxy, the certificate and a health check.
- Containers and stacks: single containers or multi-service stacks, started in order and verified.
- CI and developer tooling: GitLab, Gitea, ArgoCD and registries, upgraded by the same plan with a new version.
- Full environment rollout: from a blank host to a running environment, in one plan.
- Security
- The same posture on every host, and a record that shows it.
- Server hardening: one security baseline on every host you onboard.
- Access and identity: onboard people, rotate keys, keep least privilege true.
- Certificates and TLS: renew and reload before anything expires.
- Security audit: a read-only sweep of the fleet into one report.
- Kubernetes
- Clusters and the platform layer on top of them, with a gate before every irreversible step.
- Cluster bootstrap: a blank server to a running cluster, gated.
- Workload deployment: deploy, update and roll back on the cluster.
- Platform layer: GitOps, registry, ingress, secrets and certificate automation.
- Cluster observability: metrics, dashboards and alerts for the cluster.
- Operations
- The sweeps and the upkeep that keep a fleet honest, on a schedule and on the record.
- Host observability: metrics, dashboards and alerts on every server.
- Scheduled health checks: a pass, warn or fail sweep of the fleet, on a cron.
- Log management: central collection, rotation and retention.
- Server onboarding: bring any new host up to your standard.
- Scheduled maintenance: patching, cleanup and rotation, scheduled once.
- Data
- Backups that are verified, restores that are rehearsed, and stateful services with production defaults.
- Backup and retention: nightly dumps, verified, retained and shipped off the host.
- Disaster recovery: an off-site snapshot, and a restore path that has been run.
- Databases and caches: stateful services with production defaults on day one.
- Environment and secrets: propagate and rotate configuration without touching each host by hand.
See the records for your own servers.
Tell us what you run and which questions your clients ask. You get a demo and your price in writing within one business day, with no call.