The workflow
can act on infrastructure.
Move past shell scripts, Jenkins glue, and manual runbooks. ops0 runs infrastructure-native workflows with approvals, branching, and real execution steps.
Discover drift, open approval, run IaC deploy, send webhook, and notify the incident channel in one parallel workflow.
Automation behaves like infrastructure, not like a checklist.
ops0 workflows are built as directed acyclic graphs, so steps can branch, run in parallel, and wait on real dependencies instead of executing as a flat sequence of boxes.
- Parallel execution for steps with no pending dependencies
- Conditional edges for success, failure, always, and expressions
- A better fit for real infrastructure flows than ticket-style automation
The workflow can act on the system, not just notify people about it.
Workflows are infrastructure-native. They can run IaC deploys, configuration deploys, Kubernetes deploys, approval gates, and HTTP webhooks inside the same graph.
- IaC deployment, configuration deployment, and Kubernetes deployment steps
- Approval gates for human review inside the flow
- Webhooks for external systems without giving up control of the main process
Human review is part of the graph, not a side channel.
Approval gates pause the workflow until the right people sign off. That makes human control a first-class step instead of something reconstructed through Slack threads and ad hoc checks.
- Required approval counts and authorized approvers are configurable
- Expiry windows and instructions stay attached to the gate
- Useful for risky changes, production deploys, and change-management workflows
Retries, timeouts, and failure policy are built in.
Infrastructure workflows fail in the real world. ops0 includes retry behavior, timeout controls, and explicit fail-or-skip policy so operators can design flows that behave predictably under pressure.
- Configurable max retries, delay, and timeout
- Fail or skip behavior per step
- Useful for long-running or flaky operational tasks
Execution context stays controlled while the graph runs.
Auth context propagates through downstream calls, webhook entrypoints use signed tokens, and execution happens inside a more controlled runtime than shell-script automation can usually offer.
- JWT context carried through downstream service calls
- Webhook entrypoints use long random tokens and short-lived auth
- Useful for connecting automation without turning the flow into a security risk
IaC, config, and runtime actions stop living in different systems.
The workflow engine matters because it ties the rest of the platform together. Discover, codify, deploy, approve, and remediate inside one graph instead of jumping between orchestration products.
- Supports platform, operations, and remediation workflows in one place
- Useful for replacing shell scripts, Jenkins jobs, and manual runbooks
- Same permissions model, same product surfaces, same governance posture
