Use cases

What teams run on Opafra.

21 plans from the library, grouped by the job they do. Each one runs as it is against your hosts, or as the start of your own. Every one of them dry-runs first, stops at a protected environment, and lands in the audit log.

Solo and small teams: You own the whole stack. Start with onboarding and backups, and stop repeating yourself.; Operations Data
Platform teams: You build the thing other teams deploy onto: clusters, GitOps, registries and the access model around them.; Kubernetes Deployment
SRE and on-call: You are the one who gets paged. Health sweeps, recovery paths and audits that hold up afterwards.; Operations Security

Deployment4

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.
systemdnginxcertbothttp.probe
How it runs
One plan carries the release: environment, process manager, reverse proxy, TLS, then a health check that has to pass before the run is called done. The previous build stays on the host until it does.
1. 1Write the environment file
2. 2Deploy the build
3. 3Configure the proxy and TLS
4. 4Run the health check
5. 5Record the release
One plan carries the release: environment, process manager, reverse proxy, TLS, then a health check that has to pass before the run is called done. The previous build stays on the host until it does.
1. 1Write the environment file
2. 2Deploy the build
3. 3Configure the proxy and TLS
4. 4Run the health check
5. 5Record the release
Containers and stacks
Single containers or multi-service stacks, started in order and verified.
dockercomposesecret://http.probe
How it runs
Images are pulled and pinned, secrets are injected from your provider at run time, and services start in dependency order. The plan reports each service healthy or stops where it is not.
1. 1Pull and pin the images
2. 2Inject secrets at run time
3. 3Start services in order
4. 4Check every endpoint
5. 5Confirm the stack is healthy
Images are pulled and pinned, secrets are injected from your provider at run time, and services start in dependency order. The plan reports each service healthy or stops where it is not.
1. 1Pull and pin the images
2. 2Inject secrets at run time
3. 3Start services in order
4. 4Check every endpoint
5. 5Confirm the stack is healthy
CI and developer tooling
GitLab, Gitea, ArgoCD, registries: the tools the team runs on.
helmcomposegitlabargocd
How it runs
Installs and upgrades of the tooling everyone depends on, written down as a plan so the next upgrade is the same plan with a new version input. Integrations and access are validated before the run finishes.
1. 1Provision the host or namespace
2. 2Install with Helm or compose
3. 3Configure integrations
4. 4Validate access
5. 5Keep the plan for the next upgrade
Installs and upgrades of the tooling everyone depends on, written down as a plan so the next upgrade is the same plan with a new version input. Integrations and access are validated before the run finishes.
1. 1Provision the host or namespace
2. 2Install with Helm or compose
3. 3Configure integrations
4. 4Validate access
5. 5Keep the plan for the next upgrade

All 4 in deployment

Full environment rollout
From a blank host to a running environment, in one plan.
postgresqlsystemdnginxcertbot
How it runs
Database, backend, frontend, proxy and certificates, brought up in order for a staging environment, a new region or a rebuild after an incident. Every phase can be gated for approval.
1. 1Prepare the hosts
2. 2Bring up the data layer
3. 3Deploy the application services
4. 4Route traffic and issue certificates
5. 5Smoke test and sign off
Database, backend, frontend, proxy and certificates, brought up in order for a staging environment, a new region or a rebuild after an incident. Every phase can be gated for approval.
1. 1Prepare the hosts
2. 2Bring up the data layer
3. 3Deploy the application services
4. 4Route traffic and issue certificates
5. 5Smoke test and sign off

Security4

The same posture on every host, and a record that shows it.

Server hardening
One security baseline on every host you onboard.
ufwsshdunattended-upgradesaudit
How it runs
Firewall rules, SSH controls, unattended updates and an intrusion prevention service, applied as one plan. The final step audits the result, so a host is either at baseline or the run says why not.
1. 1Set the firewall rules
2. 2Harden SSH
3. 3Enable unattended updates
4. 4Install intrusion prevention
5. 5Audit the result
Firewall rules, SSH controls, unattended updates and an intrusion prevention service, applied as one plan. The final step audits the result, so a host is either at baseline or the run says why not.
1. 1Set the firewall rules
2. 2Harden SSH
3. 3Enable unattended updates
4. 4Install intrusion prevention
5. 5Audit the result
Access and identity
Onboard people, rotate keys, keep least privilege true.
useraddauthorized_keyssudoersaudit
How it runs
Accounts and authorised keys resolved from one list, applied to every host, and audited afterwards. Rotating a key is a run with a diff, not an afternoon with a spreadsheet.
1. 1Resolve the access list
2. 2Create or update accounts
3. 3Deploy and rotate keys
4. 4Apply sudo policy
5. 5Audit the final state
Accounts and authorised keys resolved from one list, applied to every host, and audited afterwards. Rotating a key is a run with a diff, not an afternoon with a spreadsheet.
1. 1Resolve the access list
2. 2Create or update accounts
3. 3Deploy and rotate keys
4. 4Apply sudo policy
5. 5Audit the final state
Certificates and TLS
Renew and reload before anything expires.
certbotopensslnginxschedule
How it runs
Expiry is checked across every domain on a schedule, certificates are renewed where they are due, and the services that hold them are reloaded. An expired certificate in production stops being a class of incident.
1. 1Check expiry on every domain
2. 2Flag what is due
3. 3Renew and install
4. 4Reload the services
5. 5Confirm and report
Expiry is checked across every domain on a schedule, certificates are renewed where they are due, and the services that hold them are reloaded. An expired certificate in production stops being a class of incident.
1. 1Check expiry on every domain
2. 2Flag what is due
3. 3Renew and install
4. 4Reload the services
5. 5Confirm and report

All 4 in security

Security audit
A read-only sweep of the fleet into one report.
sssystemctljournalctlreport
How it runs
Open ports, running services, authentication logs and policy signals, gathered from every host without changing any of them. The run itself is the evidence that nothing was touched.
1. 1Scan ports and firewall state
2. 2List running services
3. 3Review authentication logs
4. 4Evaluate the policy checks
5. 5Produce the report
Open ports, running services, authentication logs and policy signals, gathered from every host without changing any of them. The run itself is the evidence that nothing was touched.
1. 1Scan ports and firewall state
2. 2List running services
3. 3Review authentication logs
4. 4Evaluate the policy checks
5. 5Produce the report

Kubernetes4

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.
kubeadmcontainerdcnikubectl
How it runs
A single-node or multi-node cluster on any server. The control plane, networking and access are each a phase, and the phases that cannot be undone wait for approval.
1. 1Prepare the hosts
2. 2Initialise the control plane
3. 3Install networking
4. 4Join the workers
5. 5Validate cluster health
A single-node or multi-node cluster on any server. The control plane, networking and access are each a phase, and the phases that cannot be undone wait for approval.
1. 1Prepare the hosts
2. 2Initialise the control plane
3. 3Install networking
4. 4Join the workers
5. 5Validate cluster health
Workload deployment
Deploy, update and roll back on the cluster.
kubectlhelmkustomize
How it runs
Manifests or charts applied with readiness checks between stages, and a rollback step that is part of the plan rather than an afterthought. Every release is a run with a revision on it.
1. 1Apply the workload
2. 2Watch the rollout
3. 3Check readiness
4. 4Run the smoke tests
5. 5Confirm, or roll back
Manifests or charts applied with readiness checks between stages, and a rollback step that is part of the plan rather than an afterthought. Every release is a run with a revision on it.
1. 1Apply the workload
2. 2Watch the rollout
3. 3Check readiness
4. 4Run the smoke tests
5. 5Confirm, or roll back
Platform layer
GitOps, registry, ingress, secrets and certificate automation.
argocdharboringress-nginxcert-manager
How it runs
The layer between a bare cluster and something teams can deploy onto. Each component is a phase with its own validation, so the platform is either complete or the run says which part is not.
1. 1Install ingress and networking
2. 2Deploy the GitOps controller
3. 3Set up the registry and secrets
4. 4Configure certificate automation
5. 5Validate the platform
The layer between a bare cluster and something teams can deploy onto. Each component is a phase with its own validation, so the platform is either complete or the run says which part is not.
1. 1Install ingress and networking
2. 2Deploy the GitOps controller
3. 3Set up the registry and secrets
4. 4Configure certificate automation
5. 5Validate the platform

All 4 in kubernetes

Cluster observability
Metrics, dashboards and alerts for the cluster.
prometheusgrafanaalertmanager
How it runs
The collection stack, the dashboards and the alert rules installed together, with a diagnostics step that proves the signals are arriving before the run is called complete.
1. 1Deploy metrics collection
2. 2Install the dashboards
3. 3Configure alert rules
4. 4Run diagnostics
5. 5Validate coverage
The collection stack, the dashboards and the alert rules installed together, with a diagnostics step that proves the signals are arriving before the run is called complete.
1. 1Deploy metrics collection
2. 2Install the dashboards
3. 3Configure alert rules
4. 4Run diagnostics
5. 5Validate coverage

Operations5

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.
node_exporterprometheusgrafana
How it runs
Collectors on each host, retention set, the common dashboards imported and alert thresholds in place. Problems surface as alerts rather than as tickets from the people they affected.
1. 1Deploy the collectors
2. 2Set retention
3. 3Import the dashboards
4. 4Set alert rules
5. 5Validate the signals
Collectors on each host, retention set, the common dashboards imported and alert thresholds in place. Problems surface as alerts rather than as tickets from the people they affected.
1. 1Deploy the collectors
2. 2Set retention
3. 3Import the dashboards
4. 4Set alert rules
5. 5Validate the signals
Scheduled health checks
A pass, warn or fail sweep of the fleet, on a cron.
schedulesystemctldfopenssl
How it runs
Resource thresholds, service availability, certificate validity and reachability, checked on every host on a schedule. Each sweep is a run, so the history is the trend.
1. 1Sweep the inventory
2. 2Check resource thresholds
3. 3Check service availability
4. 4Check certificate expiry
5. 5Produce the status report
Resource thresholds, service availability, certificate validity and reachability, checked on every host on a schedule. Each sweep is a run, so the history is the trend.
1. 1Sweep the inventory
2. 2Check resource thresholds
3. 3Check service availability
4. 4Check certificate expiry
5. 5Produce the status report
Log management
Central collection, rotation and retention.
journaldlogrotatevector
How it runs
Shipping configured to your collector, rotation and retention enforced on the host, and the disk reclaimed on a schedule. Delivery is verified at the end of every run.
1. 1Configure collection
2. 2Set retention
3. 3Automate rotation
4. 4Clean expired logs
5. 5Verify delivery
Shipping configured to your collector, rotation and retention enforced on the host, and the disk reclaimed on a schedule. Delivery is verified at the end of every run.
1. 1Configure collection
2. 2Set retention
3. 3Automate rotation
4. 4Clean expired logs
5. 5Verify delivery

All 5 in operations

Server onboarding
Bring any new host up to your standard.
aptsshdinventoryaudit
How it runs
Baseline configuration, required packages, registration in the inventory and a validation pass. A host that ran this plan is at the standard; a host that did not is visible in the inventory as such.
1. 1Apply the baseline
2. 2Install the required packages
3. 3Register in the inventory
4. 4Run validation
5. 5Mark the host ready
Baseline configuration, required packages, registration in the inventory and a validation pass. A host that ran this plan is at the standard; a host that did not is visible in the inventory as such.
1. 1Apply the baseline
2. 2Install the required packages
3. 3Register in the inventory
4. 4Run validation
5. 5Mark the host ready
Scheduled maintenance
Patching, cleanup and rotation, scheduled once.
aptcronchronyaudit
How it runs
Updates, stale resource cleanup, credential rotation and time sync, run on a cron with overlap protection. Each run reports exactly what it changed on each host.
1. 1Apply updates
2. 2Rotate expiring credentials
3. 3Clean stale resources
4. 4Check service health
5. 5Report what changed
Updates, stale resource cleanup, credential rotation and time sync, run on a cron with overlap protection. Each run reports exactly what it changed on each host.
1. 1Apply updates
2. 2Rotate expiring credentials
3. 3Clean stale resources
4. 4Check service health
5. 5Report what changed

Data4

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.
pg_dumpgziprcloneschedule
How it runs
A compressed dump, an integrity check on the file it produced, a retention policy applied to the older ones, and a sync to remote storage. The report says which backup exists where.
1. 1Dump and compress
2. 2Verify the archive
3. 3Apply retention
4. 4Sync to remote storage
5. 5Report
A compressed dump, an integrity check on the file it produced, a retention policy applied to the older ones, and a sync to remote storage. The report says which backup exists where.
1. 1Dump and compress
2. 2Verify the archive
3. 3Apply retention
4. 4Sync to remote storage
5. 5Report
Disaster recovery
An off-site snapshot, and a restore path that has been run.
tarpg_dumprclonerestore
How it runs
System configuration, every database, application files and the proxy configuration, archived and shipped off-site. The last step restores into a scratch host, so the recovery plan is one that has actually worked.
1. 1Snapshot the system configuration
2. 2Dump every database
3. 3Archive the application files
4. 4Ship off-site
5. 5Rehearse the restore
System configuration, every database, application files and the proxy configuration, archived and shipped off-site. The last step restores into a scratch host, so the recovery plan is one that has actually worked.
1. 1Snapshot the system configuration
2. 2Dump every database
3. 3Archive the application files
4. 4Ship off-site
5. 5Rehearse the restore
Databases and caches
Stateful services with production defaults on day one.
postgresqlredisrabbitmq
How it runs
Databases, caches and brokers installed with authentication, persistence, memory limits and connection checks set from the first run, rather than discovered during the first incident.
1. 1Provision the service
2. 2Apply production configuration
3. 3Set authentication and limits
4. 4Configure persistence
5. 5Validate connectivity
Databases, caches and brokers installed with authentication, persistence, memory limits and connection checks set from the first run, rather than discovered during the first incident.
1. 1Provision the service
2. 2Apply production configuration
3. 3Set authentication and limits
4. 4Configure persistence
5. 5Validate connectivity

All 4 in data

Environment and secrets
Propagate and rotate configuration without touching each host by hand.
vaultinfisicalsystemdaudit
How it runs
Values resolved from your secret manager at run time, written to the target hosts, dependent services restarted and the result verified. Secrets are references in the plan and redacted in the log.
1. 1Resolve from the secret manager
2. 2Write to the target hosts
3. 3Restart the affected services
4. 4Verify the new configuration
5. 5Audit secret use
Values resolved from your secret manager at run time, written to the target hosts, dependent services restarted and the result verified. Secrets are references in the plan and redacted in the log.
1. 1Resolve from the secret manager
2. 2Write to the target hosts
3. 3Restart the affected services
4. 4Verify the new configuration
5. 5Audit secret use

Every plan here runs as it is, 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 draft be written against your inventory.

Request access

What teams run on Opafra.

Deployment4

Application deployment

Containers and stacks

CI and developer tooling

Full environment rollout

Security4

Server hardening

Access and identity

Certificates and TLS

Security audit

Kubernetes4

Cluster bootstrap

Workload deployment

Platform layer

Cluster observability

Operations5

Host observability

Scheduled health checks

Log management

Server onboarding

Scheduled maintenance

Data4

Backup and retention

Disaster recovery

Databases and caches

Environment and secrets

Every plan here runs as it is, or as the start of yours.