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

Use Teardown deployment for the selected deployment and confirm its exact name. On versions with the teardown admission fence, Remove assignments first marks the deployment as tearing down, then drains its owned assignments. Apply, source changes and reconciliation cannot recreate assignments behind that fence. An active retarget/recovery operation refuses teardown; inspect and complete its supported recovery path first.

Wait for the removal acknowledgements, then re-list the deployment and its Worker assignments. A Worker timeout, incomplete acknowledgement or changed assignment keeps removal unresolved. Do not treat an HTTP refusal as successful cleanup or force-delete recovery evidence. Metrics ingestion and canonical history settlement are a separate follow-up and are not proof that the Worker is still executing.

When assignments are absent, Delete deployment record uses the retirement path for the remaining owned definitions and channels. Shared resources and retained recovery evidence remain protected. Re-list Jobs, channels, Worker-group references and external fixtures whose cleanup you intend to claim. If ownership is ambiguous, leave the resource in place and investigate rather than deleting by prefix.

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