Deployment Manager

Deployment Manager turns an immutable workflow version into concrete desired state. It expands the graph, resolves transport and placement, and shows a reviewable plan before apply.

stateDiagram-v2
  accTitle: Deployment lifecycle and recovery paths
  accDescr: A published workflow is planned, approved, applied, converged, and proven ready. Changed intent returns to planning. Rejection, uncertainty, or a terminal finding enters a blocked state that must be inspected and corrected before re-planning. Removal ends only after owned artifacts are absent.
  [*] --> Published
  Published --> Planned: plan
  Planned --> Published: workflow or intent changed
  Planned --> Applying: approved apply
  Applying --> Converging: accepted
  Applying --> Blocked: rejected or uncertain
  Converging --> Ready: assignments ready
  Converging --> Blocked: terminal finding
  Blocked --> Planned: inspect, correct, re-plan
  Ready --> Planned: new version or intent
  Ready --> Removing: approved removal
  Removing --> [*]: owned artifacts absent

Create and plan

1. Select a published workflow version and choose Plan and register, or create a deployment from Deployment Manager.
2. Give the deployment a stable name and choose the intended worker group.
3. Complete any blueprint or workflow parameters.
4. Choose Plan.
5. Review the exact workflow version, generated jobs/channels, placement, replicas, credentials/readiness findings, warnings, destructive changes, and difference from the last apply.

A plan is a preview. It makes no runtime-effect claim. Re-plan whenever the workflow, group membership, bindings, or desired state changes; never apply a stale preview.

Apply and wait for readiness

Choose Apply only when the fresh plan matches the approved change. Record the deployment and plan identities. Then inspect lifecycle events and desired versus observed status until generated jobs are assigned and ready—or a clear terminal/blocking finding appears.

Apply acceptance means the control plane accepted desired state. It does not mean all workers converged or that data reached a destination.

Prove the running outcome

1. Confirm worker serviceability, not just heartbeat.
2. Inspect generated job state, logs, notifications, metrics, and traces.
3. Compare per-stage and per-branch counts with the input contract.
4. Check quarantine, retry, dead-letter, loss, duplicate, and ordering evidence.
5. Read back every external destination whose effect you intend to claim.

Use Runtime Evidence and Receipts for the evidence ladder and Pipeline Integrity for conservation.

Correct desired state

Create a new workflow version or update deployment intent, then re-plan and review the diff. Placement decisions are intentionally sticky; changing worker groups or selecting explicit recompute still requires a new plan and apply.

Reconciliation compares desired and observed state and can converge supported drift. It does not create universal automatic failover. Capacity, connectivity, authorization, credentials, state, storage, and input ownership remain topology-specific.

Interrupted apply

Do not click Apply repeatedly. First inspect proposal/status and lifecycle events to determine whether the server accepted the operation, is converging, rejected it, or requires a fresh plan. Preserve the original plan identity and use only a release-supported recovery path.

Tear down

Preview removal where available. Verify the deployment and every generated artifact carries the recorded run ownership, then remove the exact deployment. Re-list deployments, jobs, channels, worker-group references, and external fixtures. If ownership is ambiguous, leave the resource in place and escalate instead of deleting by prefix.

For the same lifecycle through MCP, see Author and Deploy Workflows.