Orchestration

The orchestrator runs a set of components in dependency order, dispatching each step to its capability. It contains no per-component code. There are two modes, and both make pipeline count independent of component count.

Interpret mode runs the declarations directly; generate mode synthesizes CI YAML from them. Same contract underneath.

Interpret mode

chant generates one orchestrator Op that reads the declarations, orders them with chant graph --components (dependency order from each component’s dependsOn, plus parallel-safe waves), and drives each composition. No per-component pipeline files exist.

The orchestrator is an Op, so it runs local by default on the in-process executor. Phase sequencing, retries, activity profiles, and onFailure saga rollback all work locally with nothing installed.

Temporal is optional

Temporal is required only for components whose composition includes a gate (a durable human-approval wait) or that need durable crash-resume. Schedules do not require it — a schedule externalizes to any native scheduler (CI schedule:, K8s CronJob, EventBridge). Graduation is per-component via one flag — chant run --components <name> --temporal compiles the component’s composition to a Temporal workflow/worker (phases → workflow, capability steps → activities, gate → durable wait-for-signal, onFailure/rollback → saga compensation, mirroring Temporal::Op codegen) and runs it durably; the component definition does not change. See chant run and Local vs Temporal.

Release recording stays outside the workflow

On a successful deploy, chant run --components auto-emits a release-ledger record — always as a CLI post-run step, on both the local executor and --temporal, never inside the generated workflow itself. The workflow returns its final phase outputs so the CLI can read the published digest once the run reports COMPLETED; a ledger write is a non-deterministic side effect (git, network, wall-clock time) that has no business running as workflow code.

Generate mode

The same declarations synthesize plain CI YAML through the GitHub, GitLab, or Forgejo lexicon. Pipeline files still exist, but nobody maintains them by hand, and a cross-cutting change is one edit to the generator. The generated YAML is a thin trigger and runner; the deploy logic stays in the component, not the YAML.

The two compose: interpret mode behind a thin generated CI trigger.

Execution backends and the default profile

The orchestrator is a backend interface, not one engine. Two axes swap independently and a component definition does not change across them: the trigger/scheduler host (when and what to invoke) and the execution engine (how a run executes).

• General-consumption default. Plain CI (generated) for the trigger and runner, the local executor for one-shot deploys, native scheduling. Zero exotic dependencies — this is what keeps the model broadly adoptable rather than “requires our stack.”
• Cloud/k8s-native. Lean on what the platform already reconciles and schedules — CronJob/Jobs/Argo on k8s, native schedulers and CloudFormation deploy on AWS.
• Opt-in advanced backends. Temporal as the durable execution engine for gated or crash-resumable components; Dagster or Airflow as a team-owned trigger host that invokes chant run. Chosen when a team needs or owns them, never baseline.

Keep logic out of the trigger

When a team-owned scheduler (Dagster, Airflow) hosts the trigger, keep it a thin caller of the component. The moment a trigger op starts doing publish/apply/rollback itself, the logic splits across two systems and sprawl returns in a new tool.

Rollback comes free

Because each capability declares its own compensation, the orchestrator gets saga rollback without a hand-written rollback pipeline: on failure it unwinds executed steps in reverse and calls each rollback. Native rollbacks are reused where the platform provides them — cfn-deploy triggers CloudFormation’s own rollback-stack, code-deploy triggers CodeDeploy’s own automatic rollback to the last known-good revision. Where a capability has no native rollback (ecs-update-service, lambda-deploy), it declares a best-effort compensation instead (re-apply the prior state); where a component needs a truer restore than that best-effort re-apply gives, it supplies its own component-level rollback phase (the ALB/ECS pilot does this with rollback-previous). Non-auto, non-compensable cases opt out with a stated reason (noRollback: "<reason>" on the step) rather than failing silently — the COMP003 lint rule requires the reason at author time, and the driver reports the same fact at run time: a step whose capability has no rollback gets its own rollback-opted-out record in the run result, carrying that reason, rather than being passed over without a trace.

The unwind itself is not durable

The saga mechanism — reverse-order unwind, calling each executed step’s rollback — is capability-agnostic and runs identically on the local executor and on Temporal. What differs is what survives a crash during that unwind. On the local executor, rollback state lives only in the driver’s in-memory call stack: if the process dies mid-unwind, nothing resumes it, and whichever steps had not yet been rolled back stay in whatever partial state they were left in — the same boundary that already applies to forward onFailure compensation on a plain Op (see Local vs Temporal). On Temporal, the unwind is itself a sequence of durable activities, so a crash resumes from the last completed rollback step rather than restarting or abandoning it. This is why a component with a real availability requirement around its own rollback (not just its forward deploy) is a candidate for --temporal, independent of whether it also needs a gate.

What chant adds over hand-driving it

• Semantic lint on the composition. Publishes-but-never-applies, an imageRef to a phase that does not exist, a mutating capability with no rollback and no opt-out, a gate in a local-executor component, a capability named after a component. These are the long-term entropy guards a plain JSON contract cannot enforce — see the Composition lint rules (COMP001–COMP007).
• The graph and the generated driver. chant graph / describe over components; chant build emits the durable orchestrator.

Read next

• Cloud-Agnostic Boundary — what ports across clouds and what does not.
• Local vs Temporal — the executor trade-off in depth.