Repository navigation
bug: unused docker images not pruned on external remote servers #4549
Description
To Reproduce
- Add an external remote server to Dokploy.
- Publish the Docker image of an application, set up the required configurations for the application, and deploy the application using the remote server.
- Make a few deployments.
- SSH into the remote server and run
docker system df - The size shows that unused images are accumulating over each deployment, instead of being pruned.
Current vs. Expected behavior
Current Behavior:
Unused images accumulate on the external remote server with each deployment. The total image size scales linearly with the number of deployments (i.e., deployments × single image size).
Expected Behavior:
Unused Docker images on external remote servers should be automatically pruned after each deployment, consistent with the behavior on the default Dokploy server.
Docker image accumulation behaviour of the server that Dokploy is self-hosted on, and that of an external remote server, is exhibiting different behaviour. While Dokploy prunes unused images on its default server, unused images on an external remote server accumulate with each deployment, eventually exhausting the remote server's disk storage without manual intervention.
We compared the image sizes of two servers and their reclaimable memory: the default server and an external remote server. Do note that the default server runs multiple projects, whereas the remote server only runs a single project.
Default server image size: 11.06 GB
External remote server image size: 63.18 GB
The total image size of the remote server closely matches the product of the number of deployments and the size of a single image, and after observing the size of reclaimable space, we were safe to establish that our analysis was correct. The disk space issue was resolved after manual pruning.
Provide environment information
Operating System:
OS: Ubuntu 24.04.3 LTS
arch: x86-64
Dokploy version: 0.29.7
VPS Provider: Hetzner
Application: SvelteKitWhich area(s) are affected? (Select all that apply)
Remote server, Application
Are you deploying the applications where Dokploy is installed or on a remote server?
Remote server
Additional context
No response
Will you send a PR to fix it?
No
Activity
dosubot commentedon Jun 5, 2026
Hi @Adhil523! I'm Dosu and I'm helping the Dokploy team.
This is a known configuration default issue. Remote servers have
enableDockerCleanupset tofalseby default, while the main Dokploy server has it set totrueby default [1] [2]. This means automatic Docker image pruning is not running on your remote server unless you explicitly enable it.To fix this, enable the Docker cleanup setting for your remote server in Dokploy's settings. Once enabled, a daily cron job (runs at 23:50) will execute
docker image prune --all --forcealong with container and builder pruning on the remote server via SSH [3] [4].The underlying cleanup logic is identical for both local and remote servers — the same Docker commands are used, just executed over SSH for remote servers [5]. So once enabled, behavior should match what you see on your default server.
As an immediate fix for the accumulated images, you can either:
docker image prune --all --forcedirectly on the remote server via SSH (which you've already done)This default of
falsefor remote servers could arguably be changed totrueto match the main server's behavior and avoid this confusion.To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
Adhil523 commentedon Jun 5, 2026
@dosu The instructions that you provided are now working for us. However, this can pose a big issue for users who are adding their remote servers to Dokploy, expecting the same configuration as the default server. They might only realize this once their disk storage is full. The cleanup option for the remote server lacks visibility, as it is not shown in the modal for adding a new server.
A possible solution to this issue is:
Would you like us to raise a PR to implement this fix?
Adhil523 commentedon Jun 5, 2026
@dosu
dosubot commentedon Jun 5, 2026
Glad it's working now! Your analysis is spot on — this inconsistency between the default server (which defaults
enableDockerCleanuptotrue) and remote servers (which default tofalse) is a UX gap that can catch users off guard.Both of your proposed solutions are reasonable. Some context that might help:
falsetotruein PR #3064 back in December 2025, but the remote server schema was never updated to match [1].false.Given that context, your second suggestion — adding the "Enable Docker cleanup" toggle to the remote server creation modal (defaulting to
true) — might be the safer approach. It gives users visibility and control at setup time while still matching the main server's behavior. A PR implementing either fix would be a welcome contribution — I'd suggest referencing this issue in it for context.To reply, just mention @dosu.
Docs are dead. Just use Dosu.