Delete Compose service does not stop/remove containers or volumes (v0.28.8)

[alphanull]

To Reproduce

1. Deploy a Compose service (non-stack type) — confirmed with composeType: "compose"
2. Navigate to the service → Settings → Delete
3. Type the confirmation name
4. Check "Delete volumes associated with this compose"
5. Click Confirm

Current vs. Expected behavior

Expected behavior

• docker compose down is executed
• All containers are stopped and removed
• All associated volumes are removed

Actual behavior

• Dokploy internal entry deleted (/etc/dokploy/compose/<id> removed)
• Containers continue running
• Volumes remain

Provide environment information

Operating System:
  OS: Ubuntu 24.04.4 LTS
  Arch: x86_64
Dokploy version: v0.28.8
VPS Provider: Hetzner
What applications/services are you trying to deploy?
  Docker Compose service (composeType: "compose"), multi-container stack
  (Caddy, Directus, PostgreSQL/PostGIS, Redis, Astro, analytics, backup, sync)

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

Application, Docker Compose, Docker

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

Same server where Dokploy is installed

Additional context

Notes

Related to #3691 / PR #3692 which fixed the same class of bug for composeType: "stack". This issue appears to affect the composeType: "compose" code path which was not covered by that fix. Issue #433 was marked fixed but is reproducible in v0.28.8.

The Compose service was running (not manually stopped) at the time of deletion. This may or may not be a contributing factor. However, the expected behavior is that Dokploy either (a) requires the user to stop the service before deletion, or (b) stops it automatically as part of the delete operation. Currently neither happens — the UI allows deletion of a running service without stopping it, and the backend does not stop it either.

Will you send a PR to fix it?

Maybe, need help

[dosubot]

Thanks for the detailed report! I can confirm this is a genuine bug in the composeType: "compose" deletion path.

Root Cause: The removeCompose function uses a chained command:

cd ${projectPath} && docker compose -p ${appName} down --volumes && rm -rf ${projectPath}

If the compose directory doesn't exist or the cd fails for any reason, the entire chain aborts and docker compose down never runs.

Why PR #3692 didn't fix this: That PR fixed the stack type path by using docker stack rm, which doesn't need compose files. But docker compose down inherently requires the compose file context, so the same approach couldn't be applied directly.

Suggested Fix: Implement a label-based fallback. Docker Compose automatically labels all resources with com.docker.compose.project=${appName}, and Dokploy already uses this pattern elsewhere:

# Stop and remove containers
docker ps -a --filter "label=com.docker.compose.project=${appName}" -q | xargs -r docker stop
docker ps -a --filter "label=com.docker.compose.project=${appName}" -q | xargs -r docker rm

# Remove volumes (if deleteVolumes is true)
docker volume ls --filter "label=com.docker.compose.project=${appName}" -q | xargs -r docker volume rm

# Remove networks
docker network ls --filter "label=com.docker.compose.project=${appName}" -q | xargs -r docker network rm

This could be added as a fallback when the directory doesn't exist, or used universally for more robust cleanup. Happy to help if you decide to submit a PR!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}