[Bug]: Deployment failing due to helper container name being already in use

[kondziorex7]

Error Message and Logs

2025-Dec-10 10:55:21.005030
Preparing container with helper image: ghcr.io/coollabsio/coolify-helper:1.0.12
2025-Dec-10 10:55:21.487771
[CMD]: docker stop --time=30 nwg8sk48wgccksok4s8s8kog
2025-Dec-10 10:55:21.487771
Flag --time has been deprecated, use --timeout instead
2025-Dec-10 10:55:22.258395
nwg8sk48wgccksok4s8s8kog
2025-Dec-10 10:55:22.641896
[CMD]: docker rm -f nwg8sk48wgccksok4s8s8kog
2025-Dec-10 10:55:22.641896
Error response from daemon: removal of container nwg8sk48wgccksok4s8s8kog is already in progress
2025-Dec-10 10:55:23.122942
[CMD]: docker run -d --network coolify --name nwg8sk48wgccksok4s8s8kog  --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/coollabsio/coolify-helper:1.0.12
2025-Dec-10 10:55:23.122942
docker: Error response from daemon: Conflict. The container name "/nwg8sk48wgccksok4s8s8kog" is already in use by container "18fed2d934fa481bfc0f16a6338c65b9077a1ea9b5c482827827c3f22c9665ef". You have to remove (or rename) that container to be able to reuse that name.
2025-Dec-10 10:55:23.122942
2025-Dec-10 10:55:23.122942
Run 'docker run --help' for more information
2025-Dec-10 10:55:23.161878
Deployment failed: Command execution failed (exit code 125): docker run -d --network coolify --name nwg8sk48wgccksok4s8s8kog  --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/coollabsio/coolify-helper:1.0.12
2025-Dec-10 10:55:23.161878
Error: docker: Error response from daemon: Conflict. The container name "/nwg8sk48wgccksok4s8s8kog" is already in use by container "18fed2d934fa481bfc0f16a6338c65b9077a1ea9b5c482827827c3f22c9665ef". You have to remove (or rename) that container to be able to reuse that name.
2025-Dec-10 10:55:23.161878
2025-Dec-10 10:55:23.161878
Run 'docker run --help' for more information
2025-Dec-10 10:55:23.183039
Gracefully shutting down build container: nwg8sk48wgccksok4s8s8kog

Steps to Reproduce

This doesn't happen all the time, but I've found it happen most frequently for rolling deployments, however it happens with Consistent Container Names enabled too.

1. Deploy an app

Example Repository URL

No response

Coolify Version

v4.0.0-beta.444

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Ubuntu 24.04.3 LTS

Additional Information

The issue appears to be very similar to #6767 although this one should be fixed in the version we're running (v444). There is some issue with helper container that it often is still running once coolify tries to spin up a new one.

Example full log of failed deployment - https://pastebin.com/QLQEEaZN, password to access it is BRzyS0JWfr.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and agent prompts for this issue.

• Create Plan

Examples

• Example 1
• Example 2

🔗 Similar Issues

Possible Duplicates

• 6767

Related Issues

• coollabsio/coolify#6626
• coollabsio/coolify#6767
• coollabsio/coolify#5764
• coollabsio/coolify#6648
• coollabsio/coolify#5667
• coollabsio/coolify#7439
• coollabsio/coolify#3831
• coollabsio/coolify#7391

🔗 Related PRs

#7248 - fix: eliminate duplicate error logging in deployment methods [merged]
#7460 - fix: prevent cleanup exceptions from marking successful deployments as failed [merged]

👤 Suggested Assignees

• andrasbacsai
• amioranza
• elct9620
• MayiVT
• levino

---

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

[kondziorex7]

I've been debugging the issue and this could be caused by docker stop --time ... failing due to deprecated --time flag in newer docker version. I've noticed this has been fixed in #6807 so I'll update the running version and check again. I'm unsure if it wouldn't be helpful to also add a check in ApplicationDeploymentJob->graceful_shutdown_container if the container is indeed killed after returning.

[djsisson]

the coolify helper container name is uniquely generated from the deployment id, so the initial run should just be confirming that container name doesn't exist (honestly i've no idea why you even need to give it a name, since you get the id returned upon creation anyway)

the fact it didn't immediately return with no such container, implies that this deployment id was already running? which seems unusual as i cant imagine its likely to get an id clash

there is also a slight bug with rm now, in that since the helper is started with --rm upon stopping docker already initiates auto removal asynchronously, so the coolify command of docker rm returns immediately, so no longer blocks till completion. there probably should be a check here, although i do think naming this container should be unnecessary, as you can use the id returned from docker

so although its understandable, here that docker run would fail, as the rm command wouldn't block, what i don't understand is why there was a container already running with this id in the first place