Docker-image app on a floating tag (`:latest`): deploy pulls the new digest, reports success, but the Swarm task keeps running the old image

[yoavniran]

To Reproduce

1. Create an Application with sourceType = docker and set Docker Image to a floating tag — ghcr.io/<org>/<app>:latest.
2. Deploy once. It works; the service starts on whatever :latest resolves to at that moment.
3. Publish a new image to the same :latest tag from CI (new digest, same tag).
4. Trigger a redeploy via the app's deploy webhook (POST /api/deploy/<refreshToken>).
5. Dokploy pulls the new image successfully and marks the deployment Done.
6. The running container is still the old image.

Repeat steps 3–6 for a second release: still the old image. In my case production served build 1.2.0 across two subsequent releases (1.3.0 and 1.3.1), with every deployment reporting success.

Current vs. Expected behavior

Current: the deploy pulls the new digest onto the host, reports success, and the Swarm task is never replaced — the app keeps serving the previous build indefinitely. There is no error, no warning, and nothing in the deployment log that indicates the new image did not take effect.

Expected: after successfully pulling a newer digest for the configured tag, the deployed task runs that image. A deployment marked "Done" should mean the new image is running.

Provide environment information

- Dokploy **v0.30.5**
- Docker Swarm mode
- Application: `sourceType = docker`, image `ghcr.io/<org>/<app>:latest` (private GHCR, registry credentials configured)
- Deploys triggered by the per-app deploy webhook from GitHub Actions
- Host OS / arch: Ubuntu 24.04.4 LTS / x86_64
- Nodes: 1 managers / 1 workers (deployed on Manager)
- `docker version`: 29.8.0

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

The deployment log shows the pull working:

Digest: sha256:5a12fdf4f54f9bd48ff113490b367147e3a7d022cd22de3b6ad2c84f71d2b6b7
Status: Downloaded newer image for ghcr.io/<org>/<app>:latest
✅ Pulling image completed.

The new image really is on the host:

$ docker image inspect <image-id> -f '{{json .RepoDigests}}'
[
  "ghcr.io/<org>/<app>@sha256:5a12fdf4f54f..."
]

But the running container is still the old build (the app bakes its version into a file at build time):

$ docker exec <container-id> cat /app/dist/build-revision.txt
1.2.0                      # expected 1.3.1

…confirmed over HTTP from outside as well:

$ curl -s https://<app-domain>/build-revision.txt
1.2.0

And the service spec pins nothing — it carries the bare floating tag, with no @sha256: digest:

$ docker service inspect <app>-<suffix> --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}'
ghcr.io/<org>/<app>:latest

Suspected root cause

mechanizeDockerContainer (packages/server/src/utils/builders/index.ts) builds the service spec with Image taken from getImageName(), which for sourceType === "docker" returns the configured dockerImage verbatim:

const getImageName = async (application: ApplicationNested) => {
  const { appName, sourceType, dockerImage, registry, buildRegistry } = ...
  if (sourceType === "docker") {
    return dockerImage || "ERROR-NO-IMAGE-PROVIDED";
  }
  ...

So when the configured image is a floating tag, the desired state is byte-identical on every deploy. The update does increment the force counter:

await service.update({
  version: Number.parseInt(inspect.Version.Index),
  ...settings,
  TaskTemplate: {
    ...settings.TaskTemplate,
    ForceUpdate: inspect.Spec.TaskTemplate.ForceUpdate + 1,
  },
});

…but in practice the task is not being replaced with the newly pulled image. Because the spec stores an unresolved tag, nothing in the desired state ever references the digest that was just pulled.

Suggested fix: resolve the configured tag to an immutable digest at deploy time (after the pull) and write image@sha256:... into ContainerSpec.Image. That makes every deploy of a new build a genuine spec change that Swarm cannot treat as a no-op, and it has the side benefit of making docker service inspect show exactly which build is live instead of an opaque :latest. Deploying by digest is also the standard recommendation for Swarm services on mutable tags.

Will you send a PR to fix it?

No

[linear-code]

DOK-787

[djsisson]

also note there was a regression in the docker cli recently, where docker service update used to always check the registry for the digest on a service update --image and pass the digest not the tag, however that was stopped in v29, there is a pr in the docker cli to add it back in

although --force should still recreate the task, in which case the service should then have the new image, but if dokploy is passing --force anyway, i don't know why docker service isn't creating a completely new task, unless that task is failing to start?

[yoavniran]

Update — my original diagnosis was wrong. The floating tag is not the cause. The ForceUpdate bump works fine. The real problem is that the resulting task is unschedulable, and Dokploy reports the deployment as successful anyway.

What actually happens

The service publishes a host-mode port, and Dokploy deploys it start-first at 1 replica. The replacement task needs a port the incumbent still holds, so it can never start:

$ docker service inspect <svc> --format '{{json .Endpoint.Spec.Ports}}'
[{"Protocol":"udp","TargetPort":3478,"PublishedPort":3478,"PublishMode":"host"}]

$ docker service inspect <svc> --format '{{json .Spec.UpdateConfig}}'
{"Parallelism":1,"FailureAction":"rollback","Monitor":5000000000,"MaxFailureRatio":0,"Order":"start-first"}

$ docker service ps <svc> --no-trunc
Ready     Pending 39 minutes ago   "no suitable node (scheduling constraints not satisfied on 2 nodes; host-mode port already in use on 1 node)"
Running   Running 3 hours ago

docker service update --detach=false reproduces it directly — hangs at 0 out of 1 tasks indefinitely. Dokploy reports this deployment as Done. It cost me two releases serving an old build before I noticed.

I never touched Swarm Settings. Both values come from Dokploy — generateConfigContainer in packages/server/src/utils/docker/utils.ts:

...(updateConfigSwarm
  ? { UpdateConfig: updateConfigSwarm }
  : {
      // default config if no updateConfigSwarm provided
      UpdateConfig: { Parallelism: 1, Order: "start-first", FailureAction: "rollback" },
    }),

Docker's own default is stop-first; Dokploy explicitly overrides it. The node.role==manager constraint that removes any fallback node comes from the same function (Constraints: haveMounts ? ["node.role==manager"] : []). Since the spec is regenerated from these defaults on every deploy, this reproduces on a fresh install.

Ingress mode is not a workaround in this particular case: the port serves a STUN responder that must observe the client's real source address, which ingress SNAT destroys. Host-mode ports are a legitimate, supported Swarm configuration.

Confirmed fix

Swarm Settings → Update Config → Order → stop-first. Verified end to end — the same deploy now converges in ~20s where it previously hung forever:

t+0s: got='1.3.1' want='1.4.0' <- old image
t+10s: got='' want='1.4.0' <- old task stopped (stop-first)
t+20s: got='1.4.0' want='1.4.0' <- new image live

Findings

1. A deploy that never converged is reported as successful. Nothing surfaces the pending task or the scheduler's error. This is the headline — it's what turned a fixable misconfiguration into two silently-lost releases, and fixing it alone would surface Bug report: "Deploy" on Dokploy Application - Swarm mode does not update running container, but "Stop + Deploy" does #4232, Stack app: Deploy shows success ("Deployed") but does not restart the task for a pinned external image #4792, Application environment changes do not update existing Docker Swarm service environment #5193 and every other non-convergence case. Poll the service's UpdateStatus / docker service ps until the new task runs or a timeout elapses; on timeout fail the deployment and write the task's Err into the log.
2. The hardcoded start-first default cannot converge for host-mode ports at 1 replica. Use stop-first when a host-mode port is published at 1 replica, or warn in the UI.
3. RollbackConfig defaults to start-first too (same function), and FailureAction defaults to rollback — so a failed update rolls back into the identical deadlock. Fixing only UpdateConfig leaves this in place.
4. The Update Config form cannot be saved. defaultValues are all undefined and the prefill only runs if (data?.updateConfigSwarm), so a never-saved config leaves every field empty while placeholder="1" makes them look filled. Parallelism is required by the strict schema, so the visibly-complete form fails with expected number, received undefined. Seed defaults from the running service spec, or drop the misleading placeholders.
5. That form discards the error. catch { toast.error("Error updating update config") } in update-config-form.tsx — no message, no console entry, no server log. Surfacing error.message is a one-line change.

4 and 5 matter because they guard the only supported workaround for 1–3: the form that sets stop-first fails silently unless you happen to re-type a field that already looks populated.

Secondary

Two tasks were Rejected with Head "https://ghcr.io/v2///manifests/latest": unauthorized. Credentials are configured and the host pulls fine — they just aren't distributed with the service update (--with-registry-auth). Looks like #4489. Another path to a failed deploy that isn't marked failed.

Related

#2150 names this port conflict explicitly and is the closest existing match. #4232 was closed as completed with no PR linked; "Stop + Deploy fixes it" is the tell — stopping frees the host port.