OrchStep for enterprises

At enterprise scale the deploy is the easy part. The hard part is proving the deploy followed the rules: the artifact was signed and had an SBOM, the change board approved it, the rollback path was defined before anyone touched production, and every one of those facts landed in an audit trail nobody can quietly edit. You already have the heavy machinery — a CI platform, a delivery controller, a secrets manager, an artifact registry. What's missing is the legible connective tissue that ties them into one reviewable workflow.

That's the specific, narrow role OrchStep plays in an enterprise: not the platform, but the orchestration step that makes the platform's controls explicit and runnable. The whole release reads as one file in version control, so an auditor or an SRE can see exactly what runs, in what order, with which gate — instead of reconstructing it from six tools' logs.

What automation looks like at this stage

Controls live everywhere and nowhere. Signing is in one pipeline, approval is a ticket in another system, the rollback is a runbook in a wiki, and the audit trail is whatever each tool happened to log. When a regulator or an incident review asks "show me that this release was approved before it shipped," answering means an archaeology dig.

The enterprise move with OrchStep is to make a single workflow that sequences those controls — verify provenance, hold for approval when the environment demands it, deploy with a defined rollback, append to the audit trail on every outcome — and to make that workflow itself the evidence. The environment carries the policy (approval: manual, audit: enabled), so a regulated target can't be deployed any other way.

A governed release

The controlled group sets the policy; the production environment inherits it. Provenance is verified first. The approval gate fires because the environment says so, not because someone remembered. The deploy defines its rollback up front, and the finally: audit step runs whether the release succeeded, failed, or rolled back — so the trail is never missing the one entry that mattered.

name: governed
defaults:
  service: ledger
  tier: regulated
  version: "12.0.0"

# Policy lives in the environment, not in someone's memory.
env_groups:
  controlled:
    vars: { approval: manual, audit: enabled }

environments:
  production:
    group: controlled
    vars: { target: prod-region-1 }

tasks:
  # orchstep run release --env production
  release:
    steps:
      - name: provenance
        func: shell
        do: echo "verifying signature and SBOM for {{ vars.service }}:{{ vars.version }}"
      - name: approval
        if: '{{ eq vars.approval "manual" }}'
        then:
          - name: hold
            func: shell
            do: echo "{{ vars.service }} release {{ vars.version }} awaiting change-board approval"
      - name: deploy
        func: shell
        do: echo "deploying {{ vars.service }}:{{ vars.version }} to {{ vars.target }}"
        retry:
          max_attempts: 3
          interval: "5s"
          backoff_rate: 2.0
        catch:
          - name: rollback
            func: shell
            do: echo "rolling back {{ vars.service }} on {{ vars.target }}"
        finally:
          - name: audit
            func: shell
            do: echo "appended {{ vars.service }}:{{ vars.version }} to immutable audit trail"

Because the policy is data, a regulated environment behaves the same way no matter who runs it:

orchstep run release --env production

There is no path to production that skips provenance or the approval gate — they are steps in the only workflow that reaches prod-region-1. Compliance stops being a thing engineers remember and becomes a thing the workflow enforces.

Evidence you can hand to an auditor

The dry run resolves the full release for a specific environment and prints the plan without executing — every control, in order, with the approval branch active:

orchstep run release --env production --dry-run

That output is a pre-change artifact: attach it to the change ticket and the board reviews the actual plan, not a description of it. Paired with the file in version control, you have the two things audits always want — what was supposed to happen, and proof it was reviewed before it did.

What you gained

Where OrchStep is not the answer

Be precise about the boundary. OrchStep is not your secrets manager, your signing authority, or your immutable log store — the audit and provenance steps here are hooks that call those systems, not replacements for them. It's not a progressive-delivery controller either; if Argo or Spinnaker owns your rollout, let it. And it does not, by itself, satisfy a control framework — it makes your controls explicit, ordered, and reviewable, which auditors love, but the cryptographic signing and tamper-proof storage still come from purpose-built systems. Use OrchStep as the legible orchestration layer over an enterprise stack you already trust, not as the stack.

Where to go next

• Environments — encode policy as environment data
• Error Handling — catch, finally, retries, timeouts
• Previewing with Dry Run — generate a change-board artifact
• Variables & Outputs — precedence and overrides

Make every control a visible step in one reviewable workflow. Define the policy in env_groups and let the environment enforce it.