Roll out, roll back, and skip the flags.
Services grouped per stack, with running and desired, update state and ports. Create a service with its networks, mounts and health check, roll out a new image pinned to its digest, roll back when a release misbehaves, scale, redeploy, and spread the tasks over the nodes again. And when one does not run as it should: a diagnosis to read and copy, and Claude to look into it.
What you can do
Grouped per stack
Services are grouped per stack, with running and desired, the update state and the ports. A service whose image has no digest gets a warning, because nodes may then run different versions of the same tag.
A new service
The image (pinned to its digest) and the mode: replicated with a number of replicas, global, a replicated job or a global job. Then the same settings as Adjust settings. A variable can come from an existing or a new secret, as KEY_FILE=/run/secrets/….
Roll out a new image
The app looks up the digest and pins it, so the same tag again picks up a newer image behind it. You set the tasks at a time, the pause between batches, what happens when a task fails (pause, roll back or continue) and the order: stop the old task first, or start the new one first.
Roll back
A release returns errors after the rollout. The service page shows the update state with the message of the daemon, and Roll back brings back the previous settings, including the previous image.
Redeploy and scale
Redeploy replaces all tasks one by one, following the update settings. Scale sets the number of replicas.
Adjust settings
The environment, published ports, placement constraints and service labels; the overlay networks, mounts (volume, bind, tmpfs) and secrets and configs as files; CPU and memory limits and reservations, the restart policy, spreading over a node label, the maximum per node and the health check; and the entrypoint and arguments.
Private registries
For an image from a registry that needs a login, the app uses the login from docker login on this computer, like --with-registry-auth: when it creates a service, looks up a digest, rolls out or redeploys. Docker keeps it with the service, so every node can pull the image. The app stores no registry passwords itself.
Everything about one service
The service page has the tasks with their history, the logs, what the service uses (networks, secrets, configs, environment) and the raw inspect JSON.
Diagnose
One block of Markdown with its tasks and why they failed (exit code, no suitable node, too few resources), the containers on their nodes (OOM-killed, the last health checks), its placement, resources, health check, ports, mounts and networks, its events and the last 300 log lines. The app leaves out the values of environment variables and anything that looks like a password, token or key, and shows the block before you copy it into a chat or an issue. From the menu of a service, or Ctrl+K.
Ask Claude
With your own API key under Settings › AI assistant, a service gets a Claude tab. The first question sends the diagnosis; Claude then looks up what else it needs with seven tools that only read (services, tasks, logs, inspect, nodes, events and the services of a stack), and everything they return goes through the same redaction. Every lookup shows in the conversation, with the tokens it used. It changes nothing. The key is stored encrypted with DPAPI and never reaches the window.
All tasks
All tasks, filtered by node and service, with or without history. Failing tasks stand out, with their exit code and error.
Replace a task
The app removes the container of a running task on its node, like docker rm -f, and the swarm starts a new task in the same slot. For a task that hangs but does not crash.
Rebalance
A swarm never moves running tasks by itself, not even when a node comes back. Rebalance shows per node how many tasks there are now and after, and then replaces only the surplus tasks, one at a time. You can leave nodes out. docker service update --force would restart every task instead.
Diagnose
Everything about a failing service, in one block to paste.
The tasks and why they failed, the containers on their nodes, the settings that decide where and how it runs, its events and the last 300 log lines, read through the Docker context of each node. Values of environment variables and anything that looks like a secret are left out before you see it.
Ask Claude
A second pair of eyes, with your own key, that only reads.
Claude starts from the same diagnosis you would paste yourself, then asks the swarm for what it still needs: logs, tasks, the inspect of a service, the nodes, the events. Every lookup shows in the conversation, so you see what it based its answer on. Each question costs a few cents of API usage, on your own Anthropic account; without a key nothing goes to Anthropic.
Roll out
The same tag again, and still the newest image behind it.
A tag like myorg/api:2 can point to a new build tomorrow, and nodes that pull it at different moments then run different versions of the same tag. The app looks up the digest when you roll out and pins it: every node runs the same image, and rolling out the same tag again picks up whatever is behind it now.
Adjust settings
Change one setting, and the rest stays as the stack file set it.
A service from a stack carries more than the dialog shows. What you leave as it was stays exactly as the stack file set it: aliases on a network, the options of a mount, the owner of a secret file, a health check in exec form and the labels of the stack. Only what you changed is written back.
Rebalance
After maintenance, the replicas do not come back by themselves.
Drain a node, update it, set it to active again: all replicas still sit on the other nodes. Rebalance shows per node how many tasks it has now and after, and replaces only the tasks that are too many on one node, one at a time.
All features