Deploy builds new image but Swarm service keeps running old image (port already in use)

[tiefectoestrategico]

To Reproduce

1. Install Dokploy v0.2.2 on a single-node Swarm VPS (Ubuntu 22.04 x86_64, Docker 26.1.0).
2. Create a Next.js application (port 3001) named pawify-frontend-ptomtr with the Dockerfile below and deploy it from GitHub via Dokploy GUI/webhook.
3. Push a change to GitHub, trigger a new Dokploy deploy (build succeeds – “Docker Deployed: ✅”).
4. Observe that:
   • A new image is built (IMAGE_ID f24b2315f3cd, etc.).
   • Dokploy keeps the old service/container running and does not replace it.
   • Swarm shows multiple failed tasks with error no suitable node (host-mode port already in use on 1 node) and the service remains on the stale image.

Current vs. Expected behavior

Current vs. Expected behaviour

Current:

• Dokploy finishes the deploy step but the Swarm service still points to the previous image.
• New images accumulate (docker images shows many <none> dangling layers).
• Manual intervention ( docker service update --force --image <new> or stopping the service and redeploying) is required every time.

Expected:

• After each successful build, Dokploy should automatically update the Swarm service to the freshly built :latest (or timestamp/commit-tagged) image without leaving the previous container bound to the port.

Provide environment information

Operating System:  Ubuntu 22.04.4 LTS (x86_64)  
Dokploy version:   0.2.2  
Docker version:    26.1.0  
Swarm mode:        single node (manager)  
VPS Provider:      OVH VPS S 2024  
Applications:      Next.js (20-alpine) frontend on port 3001
                   Laravel + PHP 8.3 backend on port 8001 (works fine)

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

Application, Docker

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

Both

Additional context

docker service ps pawify-frontend-ptomtr --no-trunc

p4bd... pawify-frontend-ptomtr.1 pawify-frontend-ptomtr:latest Running Pending "no suitable node (host-mode port already in use on 1 node)"
f4sa... _ pawify-frontend-ptomtr.1 pawify-frontend-ptomtr:latest Running Running 11m *:3001->3001/tcp
...

Output after deploy

#21 naming to docker.io/library/pawify-frontend-ptomtr done
Docker Deployed: ✅

Will you send a PR to fix it?

Yes

[djsisson]

if you're binding to the host then you need to change the update config from the default of Order: "start-first" to "stop-first", so that you don't get the above error

Or just don't bind to the host as its not needed, since when binding to the host, you can't have zero downtime deployments, which is probably not what you want to happen.

[tiefectoestrategico]

Thank you very much, it helped me

[msjonker]

@tiefectoestrategico I'm not binding to the host, but I am experiencing this same issue, under the same circumstances (Next.js app). How did you fix this?

[tiefectoestrategico]

en puertos no agrego nada solo agrego el dominio al puerto interno, y tambien revisa tus dockerignore porque aveces una mal configuracion afecta, ademas de tener esto :
Update Config: {
"Parallelism": 1,
"Delay": 10000000000,
"FailureAction": "rollback",
"Order": "start-first"
}
Health Check:
{
"Test": [
"NONE"
]
}.
Cuentame que tal te fue

[msjonker]

in ports I don't add anything, I just add the domain to the internal port, and also check your dockerignore because sometimes a bad configuration affects, in addition to having this: Update Config: { "Parallelism": 1, "Delay": 10000000000, "FailureAction": "rollback", "Order": "start-first" } Health Check: { "Test": [ "NONE" ] }. Tell me how it went

Thanks for your reply. Unfortunately, that did not fix my issue, but I force recreate all containers on deploy and that fixed my issue.

[ahmedabdou14]

this problem still exists
it works fine until it doesnt
i cant even replicate it

it just suddenly decides to use an old image hash eventhough the compose.yml mentions latest tag. so when it doesnt find the old hash, it cant deploy. How come it does not resolve to the new version?