Remove a Docker Swarm Stack Without Losing Track of the Damage

You will finish with a controlled way to remove one or more Docker Swarm stacks, wait for the removal when that matters, and verify that the stack names have gone. The local command tested for this guide is Docker CLI 29.8.1 from the docker-ce-cli package version 5:29.8.1-1~ubuntu.24.04~noble.

Allow about ten minutes for a single stack, plus however long you need to confirm that it is safe to remove. You need Docker CLI access to a Swarm manager and the exact stack name. A normal Docker setup does not require sudo for these commands, although your Docker installation may use a socket policy or group membership that requires an administrator to arrange access.

1. Confirm the command and your manager context

Check the installed syntax first. This is read-only and does not need elevated privileges:

$ docker stack rm --help
Usage:  docker stack rm [OPTIONS] STACK [STACK...]

Remove one or more stacks

Options:
  -d, --detach   Do not wait for stack removal (default true)

The installed CLI also accepts docker stack remove and docker stack down as aliases. The manpage documents the canonical docker stack rm form and the -d or --detach option.

Check the active Swarm before you choose a target:

$ docker info --format '{{.Swarm.LocalNodeState}} {{.Swarm.ControlAvailable}}'
active true
$ docker stack ls
NAME      SERVICES
myapp     3

The exact output is host-specific. You need a manager, not merely a worker. If the node is not an active manager, connect to the manager that owns the Swarm control plane. Do not guess a stack name from a directory name.

2. Preserve a redeploy path

Before changing the cluster, locate the Compose-style deployment file, record its image references and keep any external configuration or secret source available. Docker stack removal is not an undoable transaction. The command does not save the file that was previously passed to docker stack deploy.

For a file that is already known to be the correct deployment source, make a separate copy in a protected working location if your change process requires one:

$ cp --preserve=mode,timestamps /path/to/stack.yml /path/to/stack.yml.before-rm
$ test -s /path/to/stack.yml.before-rm && echo 'redeploy file saved'
redeploy file saved

Do not treat this copy as a backup of runtime data. Named volumes and external services are separate concerns. Check your application backup and recovery process before removing a production stack.

3. Review the exact target

Set one shell variable from the name you confirmed. Quoting keeps the value as one argument, and the comparison gives you a visible checkpoint before the destructive command:

$ STACK_NAME='myapp'
$ docker stack ls --format '{{.Name}}' | grep -Fx -- "$STACK_NAME"
myapp

If the last command prints nothing, the variable does not identify a listed stack. If it prints more than one line, stop and correct the input. Do not use a broad shell expansion or a command that removes every name returned by an unreviewed filter.

4. Remove one stack and wait for the CLI

Use --detach=false when the next operational step must start only after the CLI has waited for removal:

$ docker stack rm --detach=false "$STACK_NAME"
Removing service myapp_web
Removing service myapp_worker
Removing network myapp_default

The service and network names vary with the stack. A successful command normally reports removal progress and returns a zero exit status. The command removes the Swarm objects belonging to the named stack, including its associated services, networks and secrets. It does not remove the deployment file you kept in step 2.

The default is detached operation: --detach is enabled by default, so the command does not wait for stack removal to finish. Use that only when you deliberately want to return control immediately and have a separate way to monitor completion. A detached command returning does not prove that every object has disappeared.

There is no rollback command. If you must restore the application, use the retained deployment source after checking it, for example:

$ docker stack deploy --compose-file /path/to/stack.yml.before-rm "$STACK_NAME"
Creating network myapp_default
Creating service myapp_web
Creating service myapp_worker

Review the file and the intended image versions before running that command. Redeployment recreates services and configuration; it is not a guarantee that deleted runtime state can be recovered.

5. Verify that the stack is gone

Refresh the stack list after removal:

$ docker stack ls --format '{{.Name}}' | grep -Fx -- "$STACK_NAME" || echo "stack removed: $STACK_NAME"
stack removed: myapp

For a more detailed check, inspect services by the stack label. Docker adds the com.docker.stack.namespace label to stack services:

$ docker service ls --filter "label=com.docker.stack.namespace=$STACK_NAME"
ID        NAME      MODE      REPLICAS   IMAGE      PORTS

An empty result is the useful outcome here. If services remain, confirm that you are connected to the same Swarm manager and that the filter value is exact. Do not delete individual services as a first reaction; that can obscure whether the stack removal or your inspection command is wrong.

6. Remove several stacks only after reviewing each name

The positional argument accepts multiple stack names. Review the complete list first, then pass explicit names:

$ docker stack ls --format '{{.Name}}'
staging
demo
$ docker stack rm --detach=false staging demo
Removing service staging_web
Removing network staging_default
Removing service demo_web
Removing network demo_default

This is one destructive operation covering both names. Keep the list short enough to review on screen. If one stack is production and the other is disposable, run separate commands so the checkpoint and verification remain unambiguous.

Common failure points

"This node is not a swarm manager" means the command reached a worker or a non-manager Docker context. Select the intended context with your normal Docker context procedure, or run the command on a manager. It is not a reason to add sudo.

No such stack usually means a spelling, context or manager mismatch. Run docker context show, then docker stack ls, and compare the exact names. Avoid repeating the removal command against a guessed name.

Removal appears incomplete is especially easy to misread with the default detached mode. Recheck with docker stack ls and the service-label query. If an application still has data elsewhere, inspect that system separately; stack removal is not a general storage wipe.