Managing deployments

The Deployments page lists what's live across your organization, with at-a-glance health for each:

• Deployment — the name, marked Live or Paused.
• Project — which project it belongs to (use All projects to filter to one).
• Environment — production (see below).
• Executions 24h, Success (over 30 days, amber below 90%), and Last execution.

Deploy here deploys an agent or workflow that isn't live yet. Archived deployments drop off the list.

Open a deployment to manage it across a few tabs:

• Overview — a Recent activity strip (one bar per recent execution), the active version, schedule, and key metrics; then the deployment's Structure — a read-only view of the live workflow, or a summary of the agent — with its Connections beside it. Pinned sub-workflows are listed with their versions, flagged when a newer one is available.
• Triggers — the schedules that fire it. See Triggers & schedules.
• Executions — every execution of this workflow, test runs included, each linking to its full trace.
• Versions — the full version history (see below).
• Settings — lifecycle controls (see below).

A deployment decides which connection each of its models and integrations uses. The Connections panel on the Overview lists every slot — each agent's model, each integration node's connection, each component's model — with the connection it's bound to.

• Deploying fills each slot from the connection chosen in the builder.
• Change points a slot at a different connection; Connect fills an empty one. Only connections that fit are offered — the right integration type, or a model with the capability the slot needs.
• Clear removes the deployment's choice, so the slot falls back to the connection chosen in the builder, if there is one.

A change applies immediately — from the next step that uses the slot, even in executions already running. There's no new version and no redeploy. Your choice sticks: redeploying, rolling back, or a new solution release won't overwrite a connection you picked here. That's how the same deployed work runs on production credentials in one place and test credentials in another, and how you move a live agent to a new model without touching its definition.

For a workflow, hover a slot to spotlight its node in the structure view, or click a node to find its slot.

When a slot has no connection

A slot with nothing bound shows Not connected, its node glows amber, and the deployment appears in the notifications bell as "name needs a connection" for Admins and Developers. An execution that reaches a slot nothing fills — no binding here and no connection chosen in the builder — fails straight away, naming it. This happens most often with work that arrived from elsewhere — a solution, or a definition created from YAML — without connections for this environment.

The Versions tab shows every frozen version as a timeline, with the live one marked Active. To move the deployment to a different version — whether rolling back to an earlier one or forward to a newer one — click Promote to active on that version.

Promotion is instant and atomic: the deployment repoints to the chosen version and new executions use it immediately. Executions already in progress are unaffected, your connection choices are kept, and nothing is lost — you can promote a previous version again at any time. This makes rollback a safe, one-click action.

The Settings tab controls the deployment's lifecycle:

• Pause — stops the deployment's schedules. It can still be run on demand — from Compass Chat, the API, or a solution. Resume restarts the schedules.
• Archive — retires the deployment. Its schedules stop, its past executions stay readable, and it can no longer be run. Archiving can't be undone from the Console; deploying the same workflow again creates a new deployment.

Once live, a deployment can be run in several ways:

• Compass Chat — add it to chat's tools, set to Live.
• On a schedule — automatically, on a timetable.
• Through the API — from your own code.
• From a solution — a solution's app runs its own deployments.
• As a tool or step of other deployed work.

Today every deployment runs in a single production environment. Support for multiple environments (such as a separate staging target) is reserved for a future release — until then, connection bindings are how one piece of work runs against different credentials.

Deployments that belong to a solution move with the solution's releases: their versions can't be promoted or archived from here. You can still bind their connections and pause or resume them.