Daily Docker Cleanup removes images built by Dokploy-managed Compose services

[alphanull]

To Reproduce

1. Deploy a Docker Compose stack via Dokploy that includes a one-off/sidecar service built from source (e.g. a backup runner with entrypoint: ["true"] and restart: "no")
2. Enable "Daily Docker Cleanup" (Settings → Web Server)
3. Wait for the cleanup cron to run (daily at ~23:50)
4. Observe that the built image is deleted because no running container references it
5. Any process that depends on the image now fails with: (HTTP code 404) no such container - No such image: <project>_<service>:latest

Current vs. Expected behavior

Current: Daily Docker Cleanup runs docker image prune -a --force, which removes ALL images not referenced by a running container — including images that Dokploy itself built via docker compose ... --build.

Expected: Images belonging to services within Dokploy-managed Compose stacks should be excluded from automated cleanup. Dokploy builds these images as part of the deployment; deleting them breaks the deployed stack.

Provide environment information

Dokploy Version: v0.28.4
OS: Ubuntu (Hetzner VPS)
Deployment: Self-hosted, same server

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

Root Cause

The cleanup executes docker image prune -a --force which is an indiscriminate operation. It does not distinguish between:

• Truly orphaned/leftover images from old deployments
• Images actively used by Compose services that run on-demand (job runners, sidecar containers, one-off tasks)

Any Compose service that is not continuously running (e.g. a backup runner that starts on-demand, exits, and is removed) will have its image deleted by the next cleanup cycle.

Impact

This creates a recurring failure pattern:

1. Deployment works fine initially
2. Cleanup runs overnight → image deleted
3. On-demand service fails → manual redeploy required to rebuild image
4. Cycle repeats daily until cleanup is disabled

Suggested Fix

At minimum, exclude images that match Compose services managed by Dokploy. The Compose project name and service labels (com.docker.compose.project, com.docker.compose.service) provide enough information to identify these images.

Alternatively, offer more granular cleanup options (retention count per repo, grace period) instead of the blunt prune -a --force.

Evidence

Dokploy container logs show the cleanup executing nightly:

Docker Cleanup 3/9/2026, 11:50:00 PM]  Running docker cleanup
Docker Cleanup 3/10/2026, 11:50:00 PM]  Running docker cleanup

Database confirms the setting was enabled:

SELECT "enableDockerCleanup" FROM "webServerSettings";
-- Result: t (true)

Will you send a PR to fix it?

No

[dosubot]

Hi @alphanull! I'm Dosu and I’m helping the dokploy team.

Your analysis is spot-on. I can confirm this is a known design limitation in Dokploy's cleanup implementation.

Root cause confirmed: The cleanup runs docker image prune --all --force at 23:50 daily with no filters or label-based exclusions, even though Dokploy extensively labels containers with com.docker.compose.project and similar metadata.

Related issues: This cleanup behavior has caused problems in other scenarios:

• #3392 - Cleanup conflicts with volume backup operations
• #3307 - Race condition deletes images during backups
• #2551 - Cleanup breaks rollback capability by removing stopped containers Swarm needs

Current workaround: The only option is disabling the feature entirely via Settings → Web Server, as there are no configuration options for exclusions, filters, or schedule adjustment—just an on/off toggle.

Your suggested fix (using Compose labels to exclude managed images) would be the right approach and aligns with how Dokploy already identifies its resources.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[alphanull]

Hey Dosu, Yeah I disabled this setting for now. But it would be nice to have at least some documentation about this behavior, or just a setting that makes the cleanup less agressive. It was quite hard to debug this, but thanks to Claude (who also wrote the Iissue, not this reply though) we finally found the root cause, after a few days of fixing the runner, only to see it destroyed again.