# Swarm and Compose

Source: https://laraport.app/docs/swarm-compose/

> Docker Swarm service tasks, redeploys, rollbacks and scaling, and Compose pull, recreate and update, each with the exact command. Works with Dokploy.

The Docker tab of a container adds actions for the way it was deployed: Swarm service actions for a Swarm task (Dokploy apps are Swarm services), Compose actions for a container started by Docker Compose. Every action asks first and shows the exact command.

Coolify containers get no Compose actions: Coolify writes their compose file again on every deploy, inside its own helper container, so redeploy or restart them in Coolify.

## Swarm services

### Service tasks

**Service tasks** lists every task of the service with its state, node, image and, in full, why it failed (`docker service ps --no-trunc`): `no suitable node`, `non-zero exit (137)`, an unhealthy container. This is where to look when a deploy does not come up.

| Key | Action |
|---|---|
| `enter` | One task in full: ID, state, desired state, error, node, image, ports |
| `u` | Redeploy the service |
| `b` | Roll back the service |
| `S` | Scale the service |
| `r` | Read the tasks again |

### Redeploy, roll back, scale

| Action | Command | What it does |
|---|---|---|
| **Redeploy service** | `docker service update --force` | Replaces every task with the same image |
| **Roll back service** | `docker service rollback` | Returns to the previous spec |
| **Scale service** | `docker service scale` | Sets the number of replicas, from 0 (stops every task) to 50 |

They are on the Docker tab, and on the tasks screen with `u`, `b` and `S`. After each, laraport waits for the service to converge and reloads the tasks. A global service runs one task on every node, so it cannot be scaled.

Restarting a Swarm task from the container list (`R`) restarts only that task, and Swarm starts a replacement. The confirmation points to **Redeploy service** for restarting the whole service.

### Old tasks and settings

Each redeploy leaves stopped tasks behind. The container list collapses them, see [Old tasks and hidden containers](https://laraport.app/docs/container-list/#old-tasks-and-hidden-containers). Container settings can be bound to the service so they survive redeploys, see [Container settings](https://laraport.app/docs/container-settings/#what-a-setting-is-bound-to). [Events](https://laraport.app/docs/events/) on the Docker tab of a task covers every task of its service.

## Compose projects

A container started by Docker Compose gets three actions:

| Action | Command | What it does |
|---|---|---|
| **Pull image** | `docker compose pull <service>` | Downloads a newer image of the service, if the registry has one. Nothing restarts |
| **Recreate (up -d)** | `docker compose up -d --no-deps <service>` | Recreates the service if its image or configuration changed. Other services are not touched |
| **Update project** | `docker compose pull`, then `docker compose up -d` | Pulls every image of the project, then recreates each service that changed. Stopped services are started |

The confirmation shows the compose command, the directory it runs in and what happens.

### Where they run

The commands run where the project was started from, read off the container's labels: its working directory, its compose files and its env files. If one of them is not on the server, because the project was started elsewhere or its files moved, the command stops and says which file is missing.

laraport uses `docker compose` (v2), or `docker-compose` where only v1 is installed. A custom docker command such as `sudo -n docker` applies here too.

The [journal](https://laraport.app/docs/journal/) records the compose command. On a [read-only server](https://laraport.app/docs/read-only/) Swarm and Compose actions are refused.