Stacks

A Stack manages an application described by one or more Compose files. On a Docker Standalone Platform it runs as a Compose project; on a Swarm Platform it runs as a native Docker Stack.

In Inspect, expand Processes below the inspection data. For a Standalone Stack, it follows the selected container. For a Swarm Stack, select a Service and then choose a running Task inside Processes. Process reads require Platform Read and Inspect permission and use the container Processes view.

HealthCopy Anchor Link

On Docker Standalone, deployment completes when Compose and any deployment hooks succeed. Containers may still be starting at that point. The Health indicator tracks their healthchecks separately and can show Starting or Unhealthy after a successful deployment.

The Health icon in the table and beside Backup summarizes current containers. Hover or select it for counts and coverage; View details lets you choose a container from a dropdown with health status icons and view its history. The dialog keeps coverage warnings brief; aggregate counts remain in the hover card. History requires access to its Platform; probe details retain the Inspect permission.

The Services table also shows health for each container or Swarm service. Swarm service summaries use current task observations; missing observations remain Unknown. Expand a service to see health for its tasks.

A Stack is Healthy only when all required active containers have fresh passing checks. Failures remain visible alongside unchecked, missing or stale members. For Standalone Stacks, the summary retains membership from a successful full Apply, even if the Stack later stops or becomes degraded. Saving an edit does not change it. Intentional stops, inactive profiles and proven completed one-shot jobs are handled separately from failures.

Existing Standalone Stacks without a retained definition need a successful full Apply to establish expected membership. A failed, interrupted, or service-scoped Apply can leave mixed membership, so expected coverage remains unknown until a full Apply succeeds.

For Git Compose projects, unresolved Compose definitions, or incomplete Swarm membership, expected coverage may be unknown. The summary explains this instead of claiming everything is healthy. Swarm observations come from each task's own node and exclude superseded tasks.

Health updates automatically. Health Filter can match several categories in a mixed Stack. Hiding Health in Columns pauses its filter without clearing your selection. Large detail lists show up to 200 containers, prioritizing failures; summary counts include all current members.

Interrupted commandsCopy Anchor Link

On Unix, cancelling or interrupting a Stack command stops its CLI or hook process and children in the same process group. Commands that deliberately create a new process group or session are outside this cleanup. This does not roll back Docker changes already accepted by the daemon or stop the deployed application containers. Closing the browser does not cancel a claimed Stack operation; check its operation history before retrying.

The Logs tab follows replacement containers during redeployment. A container being removed ends only that container's stream; logs from other members continue, and the replacement appears after inventory updates. Permission or connection failures still stop the subscription and show an error.

Deploy and rollback progress stays connected during quiet periods, such as long image pulls, with keepalive data that does not add log entries. A connection error alone does not mean the Stack operation failed; check its status and history.

Choose the sourceCopy Anchor Link

Both sources support Standalone and Swarm Platforms. Source selection controls where Citadel gets the configuration; the Platform determines how it deploys it.

Choose the deployment targetCopy Anchor Link

On Docker Standalone, the source pages describe container lifecycle actions, drift checks, and deployment settings. For a cluster, also read Swarm Stacks for Compose compatibility, rollout behavior, Task operations, and rollback limitations.

Use Deployments for individual Standalone containers or Swarm Services for independently managed Swarm Services.

Image updatesCopy Anchor Link

Checks compare the images deployed in the Stack with the registry tags. If a newer pull moves a tag away from a running image, Citadel uses that image's immutable manifest digest when available. If Docker no longer provides enough metadata for a reliable comparison, the check reports an error rather than marking the image up to date.

Redeploy pulls the service images and, when a Registry is configured, refreshes the image-update status against the deployed images. This also applies when scheduled update checks are disabled. A newer image can still be reported if the registry tag changes again during deployment.

If the status refresh fails, the deployment remains successful and its progress shows a warning. Use Check for updates to retry the check without redeploying.

DuplicateCopy Anchor Link

Copy availability is included when the resource list loads and refreshed with resource updates. Opening Duplicate does not fetch the resource details.

The same Duplicate options are available on the resource page, in each list row's action menu, and in the bottom action bar when one Stack is selected. Choosing Configuration + data from the list opens the copy wizard on the source resource's page. Unavailable data copies show a reason.

Choose Duplicate → Configuration only to open a new Stack form from the saved configuration. Review copy reviews the edited draft before saving; creating it does not Apply the Stack. The Compose project name is reset, and automatic updates, webhooks, deployment hooks and build-triggered redeployment are disabled. Drift auto-fix becomes detection only, with automatic start, resume and removal off. Enable integrations on the new Stack after reviewing their targets.

Configuration only copies settings, not volume contents. A different Compose project name does not isolate external volumes, explicit volume names or bind paths. Review the Compose configuration, bindings, networks and published ports before Apply. Git references and external dependencies remain references; duplication does not create another Git repository. History and access grants are not copied.

Duplicate → Configuration + data opens a three-step wizard: configure the name and destination Platform, choose current data or existing backups, and review the copy. Current data needs no backup policy; confirm source consistency first. For standalone Web Editor Stacks, Citadel restores declared named volumes into fresh volumes and rewrites their Compose declarations. Shared volumes are restored once. Copying to another Standalone Platform requires existing backups in a reachable S3-compatible repository. Current-data copies stay on the source Platform. Git sources, Swarm Stacks, bind mounts and storage indirection that cannot be resolved safely are blocked. See Copy a workload with data.

Backup coverageCopy Anchor Link

The backup shield at the far right of the main tab bar is available from every tab. Hover, focus, or click it to see coverage for each resolved Docker volume and bind mount, including the most recent successful backup when available. Use Configure backup to open the central policy form with the Stack or an uncovered storage target selected. Existing policy links also show coverage from shared-volume policies. See Backups for status meanings and configuration.

On standalone Docker, Stack policies discover actual volume names from owned, synchronized containers: named volumes, external volumes, and anonymous volumes with generated names. Shared volumes are backed up once; stale inventory or an unavailable container inspection blocks execution rather than omitting storage. On Swarm, coverage is limited to supported local volumes on their owning Nodes. Supported bind mounts discovered from owned containers are included in the same policy using actual host paths and exact Nodes. Host data requires Platform write access for both configuration and execution. Tmpfs, nested mounts, and container writable layers remain excluded.

Use Backup Filter at the right of the resource header to filter by backup status. The resource table displays a Backup column. Hover over its shield to see the same coverage card as on the resource page. Manual-only or disabled policies show amber, even after a successful manual run. Green requires an active schedule, a ready repository, and a successful available backup for all eligible storage. See Backup coverage for all status meanings and scheduling requirements.

Get startedCopy Anchor Link

• Deploy your first Stack.
• Adopt an existing Compose project or Docker Stack.
• Configure variables and secrets.
• Back up application data.

Local command trust boundaryCopy Anchor Link

Local pre/post-deployment shell commands run with the operating-system access of the Core or Agent executing the Stack. They are trusted code: they can access host files and any Docker daemon available to that process. Only grant this capability to users trusted with that access.

Commands receive explicit workload variables and selected tool settings (PATH, locale, timezone, proxy and CA paths), rather than the complete Core environment. Compose uses the staged working directory and private registry configuration. This reduces accidental secret inheritance; it does not sandbox shell commands.