Deployment Manager

The Deployment Manager is the control plane that turns a published workflow into concrete jobs running on workers.

Mental model: workflow → deployment → workloads

Think of Deployments as a compilation pipeline:

Published workflow version
  → deployment record (desired state + history)
  → per-worker job deployments (rendered artifacts)
  → workloads (what is actually running)

This is why the Deployment Manager is separate from the workflow editor: workflows describe intent; deployments produce concrete runnable artifacts.

The three verbs: plan, apply, reconcile

Plan

Planning is where the system compiles the workflow into deployable concrete artifacts:

• expands blueprints and imported workflow modules,
• resolves transports (and may insert required adapter jobs),
• validates bindings (channels, imports, required parameters),
• and produces a diff preview (“what will change, and where”).

Apply

Applying executes the plan:

• stages the concrete jobs,
• renders per-worker deployment artifacts,
• deploys them to the selected worker group(s),
• and records history so you can audit and roll back by deploying an older workflow version.

Reconcile

Reconcile converges “what is running” back toward “what you asked for”:

• detects drift (workers out of sync, missing replicas, changed placement),
• and re-applies the desired state when needed.

Managed artifacts (what to edit vs what to regenerate)

When you apply a deployment, the system generates managed job artifacts from your workflow. In general:

• Change behavior by editing the workflow (or selected blueprints) and applying a new workflow version.
• Avoid “hot-editing” the generated jobs directly; those changes will look like drift and can be overwritten by reconcile. If you need a bespoke job outside the deployment manager, clone it into an unmanaged copy and manage it through Jobs.

Placement and scaling (worker groups + replicas)

Workflows are designed to run across worker groups:

• Placement chooses where each step runs (which worker group).
• Replicas control horizontal scale per step (and isolate noisy stages).

This lets you isolate heavy ingest from sensitive delivery, or scale routing independently from collection.

Note

Placement is intentionally “no surprises”: after an apply, placement decisions are sticky unless you re-plan/re-apply (or explicitly choose Recompute placement for next plan in the UI).

Common reasons planning or apply can fail

• Missing producers/consumers: workflows must have a complete channel graph (every channel has a producer and a consumer).
• Missing worker group / no workers available: planning can still return a preview with warnings, but apply cannot place jobs until an eligible worker group exists.
• Missing secrets/config required by a selected blueprint (credentials, endpoints, storage paths).
• Incompatible artifacts: license or runtime feature requirements are not met (for example, external workers unavailable in Community Edition).

Next: follow Tutorial: Quickstart File Store Roundtrip for an end-to-end walkthrough.