Where OrchStep Runs
One single binary, four kinds of work - cloud-native deployments, infrastructure, multi-step workflows, and day-2 automation
OrchStep is a single static binary with no runtime and no daemon. That one property is what lets it show up everywhere the same way - on your laptop, in a container, in CI, or behind an AI agent. The four contexts below are the shapes that work tends to take.
Ships as one static binary - no runtime, no daemon. Drop it into any container or serverless image and run the same workflow you run locally.
Wraps the tools you already use - kubectl, terraform, aws, docker - so provisioning and deploys live in one reviewable, replayable file.
Tasks, steps, branches, loops and modules compose into multi-layer pipelines. Preview the whole chain with a dry run before anything executes.
Built for day-2 operations - deploy, rollback, db_migrate, incident runbooks - driven from the CLI, the task menu, or an AI agent over MCP.
Why one binary matters
Every context above runs the same orchstep.yml with the same engine.
There is no "works locally but not in CI" gap, because there is nothing to
install differently - you copy one binary (or curl | sh) and run it.
- Cloud-native - the binary is the whole dependency. Alpine, distroless, Lambda, a scratch image: if it can exec a file, it can run OrchStep.
- Infrastructure - OrchStep does not replace
kubectl/terraform/aws; it orchestrates them, with variables, environments, retries and assertions around the commands you already trust. - Workflows - compose tasks into branches, loops, parallel steps and reusable modules, then preview the entire chain before it runs.
- Automation - the operations you reach for under pressure (deploy, rollback, migrations, incident runbooks) become named, replayable tasks you can launch from the task menu or hand to an AI agent.
Next
- Quick Start - your first workflow in two minutes
- Your First Workflow - tasks, steps and the task menu, explained