Scheduled tasks (Server Jobs) on build servers: supported, planned, or out of scope?

[gabriel-kimutai]

Context

Since build servers landed, I've moved heavy builds off my deploy servers onto a dedicated build server. That works well, but it creates an operations gap: there's no supported, documented way to run scheduled tasks on a build server.

As far as I can tell:

• The Schedule Jobs docs list four job types (Application, Compose, Server, Dokploy Server). None of them mention build servers.
• The Build Server docs warn about disk space and suggest either enabling Docker Cleanup or creating a Scheduled Job to run docker image prune -af on the build server.
• In practice, build servers don't appear in the server picker for Scheduled Tasks

So the docs recommend something the product doesn't seem to support.

Why this matters

Build servers are, by design, the servers that accumulate the most Docker state: image layers, BuildKit cache, cloned repos. They don't run long-lived containers, so image pruning is aggressive by default. Without scheduling, the options today are:

1. SSH in and set up a host crontab by hand. This works, but it lives outside Dokploy, so there are no logs, no UI, and no visibility.
2. Rely on Docker Cleanup, if it even runs on build servers. There's a related report that daily cleanup only runs on the master and not on worker nodes (Docker cleanup does not run on worker nodes in a cluster #3193), so I'm not sure it covers build servers either.
3. Let the disk fill up until builds fail.

Use cases

• Disk hygiene: docker image prune, docker builder prune --filter until=72h, removing stale clone directories.
• Cache management: keeping BuildKit cache mounts warm but bounded. For example, prune build cache older than N days while keeping recent layers. A blanket prune -af throws away the cache that makes a dedicated build server worth having.
• Registry auth refresh: re-running docker login for registries with short-lived tokens (ECR, some GHCR setups) so pushes don't fail mid-deploy.
• Health checks: simple disk/memory checks that notify through Dokploy's existing notification providers.

Questions for maintainers

1. Is the lack of Server Job support for build servers intentional (e.g. because build servers skip parts of the standard server setup), or just not implemented yet?
2. Does Daily Docker Cleanup currently run on build servers?
3. If Server Jobs are out of scope, should the build-server docs drop the "create a Scheduled Job" suggestion and document the recommended approach instead?

Possible directions

• Minimal: allow serverType: build servers as targets for existing Server Jobs. Execution is already SSH-to-host, which is exactly what a build server needs.
• Nice to have: a built-in "build cache retention" setting per build server (e.g. keep cache for N days / up to X GB), since this is the most common reason anyone would schedule a job there.
• Docs: whichever way this goes, clarify in both the Schedule Jobs and Build Server pages what's supported.

Happy to test a branch or help with the docs update.

Environment: Dokploy , self-hosted, 1 deploy server + 1 dedicated build server, Application deployments (Dockerfile builds).

[sueun-dev]

The built-in daily cleanup has a build-server path in v0.30.7. Its startup code schedules registered servers with enableDockerCleanup set, without a build/deploy filter. Scheduled Tasks uses a different path: the picker's API explicitly selects serverType: "deploy", which explains the missing build-server entry.

I exercised those release functions in an isolated Node 24.21.0 test with database, timer and SSH stubs. Enabled build and deploy records both registered cleanup callbacks; the disabled build record did not. The build callback dispatched commands to its own server ID. This tested selection and dispatch, not live SSH or an overnight run.

Check the build server's own enableDockerCleanup setting, as the build-server docs describe. The global setting controls the Dokploy host's cleanup. The built-in commands use --all without an until filter, so this still doesn't provide your requested 72-hour cache retention.