Platform
The OpsChain platform
Describe your operations declaratively; the platform governs the execution. One control plane for operational change across cloud, on-prem, and hybrid environments — with the orchestration, automation, observability, and analytics that everything else is built on.
Looking for approvals, audit, and trust for automated actors? That lives on the Governance page.
Operations as code you can read
A workflow is a versioned, schema-validated definition of an operational process — the steps, conditions, retries, and estate-driven fan-out — authored and managed in the platform, or kept alongside your code in a git repository, in plain YAML with CEL expressions. Everything is declared and validated before anything runs: develop and test locally, review like code, then run the same definition against production under full governance.
workflow: quarterly-patch
name: Quarterly patch sweep
inputs:
reason: { type: string, required: true }
steps:
- name: preflight
for_each: ${{ estate('apps').assets }}
as: app
change: { target: ${{ app.path }}, action: patch:preflight }
- name: patch-${{ result.code }}
for_each: ${{ steps.preflight.outputs.children.filter(c, c.status == 'success') }}
as: result
change: { target: ${{ result.asset_path }}, action: patch:apply }
retries: { attempts: 2 }
- name: report
when: ${{ always() }}
change: { target: ops/reporting, action: patch:report }No approval logic in the workflow. Approval policy — who, how many, in which change windows — is bound to the estate path by your governance policy, so changing your approval rules never means changing your automation.
Unified Workflow Orchestration
Declare It. The Platform Governs the Execution.
Describe your operations declaratively: versioned, schema-validated workflows and actions — authored and managed in the platform, or kept alongside your code in git — orchestrated across cloud, on-prem, and hybrid environments from a single control plane. Humans, automation, and AI operators participate in the same workflows, under the same governance.
Declarative workflows and actions — versioned, schema-validated, reviewed like any other code
Typed workflow inputs (strings, numbers, enums, vault-backed secrets) validated before a run exists
CEL expressions everywhere: when: conditions, dynamic for_each: fan-out over your estate, and data passed between steps
Stages run sequentially or in parallel; retries and on_error: compensation are part of the language
Approval gates are enforced from the governance policy bound to the estate path — no approval code in your workflows
Nested workflows and cross-node changes compose whole-estate operations from reviewed building blocks
Governed Integrations
Integrations that don't leak authority.
Bring Terraform, Ansible, custom scripts, and the systems around them into one governed operations ecosystem — tool-agnostic, with the whole authoring loop running from a git repository you can develop and test locally. And the connections never leak authority: inbound events arrive signed and replay-protected and execute as named service accounts; outbound credentials are issued just-in-time, scoped, masked, and never persisted; every crossing is audited.
Tool-agnostic out of the box: the common action pack ships Terraform, Ansible, script, CLI, and RPC connectors — each one a typed, versioned, approval-gated action
Compose actions from actions: a step declares its typed inputs and outputs, and call sites bind them with compile-time validation; captured outputs and step artifacts flow between steps
Inbound: triggers, tickets, and webhook events start governed runs — signed, replay-protected, executing as named service accounts, never an ambient admin
Outbound: credentials are just-in-time, scoped, and masked — never persisted; connection secrets are write-only once stored
Both directions on the record: every crossing is audited, and resolutions written back carry evidence links to the governed record behind them
Git-native: author in your repository, iterate locally, and run the same definitions against your estate
See everything it connects to today — the full shipped connector matrix below ↓
Real-Time Observability
Always-On Visibility.
Full visibility into every change and workflow run as it happens. Live step logs, statuses, and events give your teams one place to watch operations across every environment — and your existing monitoring stack can subscribe to the same signals.
Real-time visibility into every change and workflow run
Live step logs streamed as automation executes
Events and notifications for the operational signals you care about
One view of activity across projects and environments
Feeds your existing monitoring and alerting tools
Analytics & Continuous Improvement
Measure. Learn. Optimise.
Your complete operational history is queryable and filterable — every change, workflow run, and event. Use it to see where time goes, find the changes that fail or wait the longest, and improve the workflows that matter.
Filterable history of changes, workflow runs, and events
Activity views across projects, environments, and assets
Spot slow or failing workflows from the recorded history
Operational data available for your own reporting and BI
What it connects to today
Every class below ships in the product now — no aspirational rows. And every connection is governed the same way: inbound crossings are signed, replay-protected, and execute as named service accounts; outbound credentials are just-in-time, scoped, masked, and never persisted; connection secrets are write-only once stored; every crossing is audited.
Execution tooling
Terraform, Ansible, scripts, CLIs, RPC — out of the box
The common action pack ships ready-to-use Terraform, Ansible, script (Bash and Python), CLI, and RPC connectors — every tool runs as a typed, versioned, approval-gated action in the same audit lane.
ITSM
Jira Service Management
Support and change tickets flow into governed work; resolutions written back carry evidence links to the governed record.
Source control & CI
GitHub — both directions
OIDC-federated identity in, just-in-time scoped tokens and signed attestations out, repository events in. No standing credentials on either side.
SIEM & audit streaming
Splunk HEC, syslog/CEF
The audit lane streams to your SIEM as it is written — the same tamper-evident history, in your tooling.
Secrets vaults
OpenBao, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
Secrets stay in vault custody and are resolved at execution time — masked in logs, never inlined into automation.
Identity
OIDC SSO, LDAP, GitHub, Google, Microsoft Entra
Your identity provider is the front door; path-based authorisation decides what each identity may touch.
Notifications
Slack, Microsoft Teams, webhooks
Approvals and operational signals reach the channels your team works in — honest in every surface.
AI model providers
Anthropic, OpenAI, Azure OpenAI
Model access is brokered by the platform: keys stay in your custody, and no key is ever placed on an agent.
Clouds & infrastructure
AWS, Azure — plus infrastructure and RPC action packs
Cloud and infrastructure change runs through the same governed workflows, approvals, and audit lane.
Everything else
The signed inbound webhook
Any system can start a governed run: the event arrives signed and replay-protected, executes as a named service account, and lands in the audit lane.
A platform is only half the story
What makes OpsChain different is the governance enforced on top of it — explicit authorisation, enforced approvals, earned trust for automated actors, and one audit lane.