Remove a Docker Swarm Stack Safely with docker stack rm

One command with no confirmation prompt takes down every service in a stack, so docker stack rm deserves a slower approach than it invites. This guide removes one or more stacks, waits for the removal when it matters, and verifies the names have gone. The command was tested on 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 it is safe to remove. What you need:

• Swarm manager access through the Docker CLI.
• The exact stack name.
• Usually no sudo. Your installation may use a socket policy or group membership that needs 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.

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 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

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

• Prints nothing. The variable does not identify a listed stack.
• Prints more than one line. Stop and correct the input.
• Never use a broad expansion. Do not remove 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. It 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.

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

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

6. Remove several stacks 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 stay unambiguous.

Common traps

• "This node is not a swarm manager". 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 a spelling, context or manager mismatch. Run docker context show, then docker stack ls, and compare the exact names. Do not repeat the removal against a guessed name.
• Removal appears incomplete. Easy to misread in 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.