Approve and run a deployment

Approval binds to one exact plan hash and expires on its own. Starting the run is a separate decision, and the server re-checks every authority when the run is queued and again when a runner claims it.

Who can do this

Workspace Owners and Administrators. Approving a deployment plan needs the deployment approval capability; approving a rollback needs the separate rollback approval capability.

Build the plan

1. On Deployments → Overview, choose Create release plan.
2. Pick the Environment, enter the Release version, the Source commit SHA, the Artifact name, the Image, and its Immutable digest.
3. Choose Build exact plan.

The plan pins the release, the environment’s workflow revision, every connection revision, the runner label requirements, and the rollback target, and hashes all of them. Its card shows the plan hash with a copy button and a trusted provenance line: No trusted provenance recorded until server-side connectors attach the repository, CI, and registry facts for the release.

Approve

Choose Approve exact plan. The confirmation lists the environment and revision, release, source commit, artifact digests, plan hash, provenance facts, and when the approval expires. For a production environment you must also tick I acknowledge this approval deploys to a production environment. The plan becomes Approved.

An approval is refused if the plan hash no longer matches, if the approval window has passed, or if the environment revision changed; in those cases the plan is marked Expired.

Start

Choose Start deployment. The confirmation shows which registered runners match the required labels; the server performs final eligibility checks (credentials, heartbeat, adapter availability) when the run is queued and claimed. Only one run can be active per environment.

Queueing is also where the execution gate and trusted provenance are enforced: outside the sandbox, the repository → CI → registry chain must be complete, or the run is denied with Trusted release provenance is incomplete.

Follow the run

Run activity lists each run with its status, attempt, runner, and the latest events. A run records a mutation boundary before its first mutating step; from then on any lost connection, cancellation, or failure produces Reconciliation required rather than a guessed outcome. See Reconcile an uncertain run.

Cancel

Cancel queued run withdraws a run before any runner claims it. Request cancellation on a running run is cooperative: the runner stops between steps, a mutating step may still finish on the remote system, and the outcome may then require reconciliation. A cancellation reason is required and recorded in the audit trail. A queued run that no runner claims before its approval expires is cancelled and its plan marked Expired.