docker-compose redeploys leave stale containers/orphans instead of cleanly recreating the stack

[ews-pgasser]

To Reproduce

1. Create a Dokploy application/compose project using composeType: docker-compose.
2. Deploy it once successfully so the stack is running.
3. Modify the compose file in a way that changes service topology — e.g. rename a service, change a network name, or remove a service that owned a volume mount.
4. Trigger a redeploy from Dokploy.
5. Observe that Dokploy runs a single docker compose -p <app> -f <path> up -d --build --remove-orphans (see createCommand in packages/server/src/utils/builders/compose.ts).
6. Inspect the running containers/networks (docker ps, docker network ls) — the old, renamed/removed service's container or network can remain, or a stale volume lock can prevent the new container from starting cleanly.

Repro repo: (add a link to a minimal docker-compose project that reproduces the renamed-service/orphan case, if you have one — issues without a reproducible example are harder for maintainers to act on)

Current vs. Expected behavior

Current behavior:
Dokploy runs a single docker compose up -d --build --remove-orphans on every deploy. When the compose file changes in ways that affect service/network identity, this can leave the stack in an inconsistent state — stale containers, dangling networks, or volume locks held by orphaned containers that --remove-orphans doesn't fully clean up.

Expected behavior:
Running docker compose pull && docker compose down && docker compose up -d --build --remove-orphans instead ensures fresh images are pulled and the previous stack is fully torn down before being recreated, avoiding the inconsistent state.

Note: this only applies to composeType === "docker-compose". stack (Swarm) deployments should be left untouched — stack deploy already handles image updates via --with-registry-auth, and stack rm/down is far more disruptive for Swarm.

Trade-off to flag: this introduces a brief window where containers are fully stopped between down and up, instead of Compose's in-place rolling recreate. Acceptable for most self-hosted setups, but worth noting for anyone relying on zero-downtime redeploys in plain docker-compose mode. Deploy time also increases slightly (three sequential docker compose calls instead of one).

Provide environment information

- Dokploy version: v0.29.14
- OS / distro: Ubuntu 24.04
- Docker version: 29.7.1, build e9452d6
- Docker Compose version: 5.4.0

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

Docker Compose

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

Remote server

Additional context

The current sanitizer (UNSAFE_COMPOSE_COMMAND regex) blocks any command containing ; & | \ $ ( ) { } < > \ \n, which means the Command override field can never express a multi-step deploy (e.g. pull && down && up -d --build`), even though that's a completely standard and safe Compose workflow, and it's actually shown as an example pattern in Dokploy's own docs/UI hints.

Will you send a PR to fix it?

Yes

[linear-code]

DOK-617