Scheduled Tasks

Pro feature, admin-only

Scheduled tasks can restart or auto-update any container on the host, so only admin role users can manage them.

Automate routine host maintenance on a cron schedule from Scheduled Tasks.

Task Types

• Prune unused images — docker image prune equivalent
• Prune unused volumes — docker volume prune equivalent
• Prune build cache — docker builder prune -a equivalent. Usually the one that matters
• Restart a container — pick any container on the host from a live dropdown
• Auto-update a container (watchtower-style) — see below

Build Cache Is Where the Disk Goes

If you only schedule one of these, schedule the build cache prune.

Every build leaves cached layers behind. Nothing removes them: Docker's own garbage collection is off unless an operator has written a builder.gc policy into /etc/docker/daemon.json, and DockPod did not collect them either before v1.17.0. So the cache grows for as long as the host keeps building.

For scale, from a real host building a handful of apps — one of them producing ~4GB images — over three months:

Builds	199
Build cache accumulated	58.4GB
Average per build	~294MB
Images reclaimable at the same moment	261MB
Volumes reclaimable at the same moment	0B

That is ~4GB a week, on a 96GB disk. The image and volume prunes ran weekly on that host and were working correctly — they recovered 10KB between them, because there was nothing else for them to find.

This is not a sign of anything misconfigured, and it does not mean an app is leaking. It is simply what a build host does when nothing collects the cache.

Nothing is lost by pruning it. Build cache holds intermediate layers of builds that already finished — no image, container, volume, or rollback target is affected. The only cost is that your next build repeats work it would otherwise have reused, so it runs slower once. On a weekly schedule that is one slow build a week.

The manual button is free

Scheduling is Pro, but the one-off Prune build cache button on the Images page is available on every plan — alongside the existing dangling-image prune. Free installs can run unlimited Git Deployments, so the cleanup itself is never gated; Pro is what saves you from having to remember it.

Auto-update, Explained

This is a minimal, self-contained version of what Watchtower does:

1. Inspect the target container to get its current image reference and image ID
2. Pull that image reference fresh
3. Compare the newly-pulled image's ID against the container's current one
4. If they differ, stop and remove the old container, then recreate it in place — same name, environment, port bindings, volumes, and restart policy — on the new image, and start it
5. If they're the same, it's a no-op — logged as "already up to date"

This works against any container on the host, not just ones DockPod deployed.

Schedule Format

Standard 5-field cron expressions (minute hour day month weekday). The create dialog includes quick presets — Every 15 minutes, Every hour, Every day at midnight, Every Sunday at midnight — or you can type a custom expression.

Enable/Disable

Toggle a task on or off directly from the list without opening the edit dialog — a disabled task's cron entry is removed from the scheduler immediately, not just hidden in the UI.

History

Every run records its outcome — success/failed status, a human-readable result message (e.g. "pruned 2 image(s), reclaimed 45MB"), and a timestamp — visible on the task's card.

A note on the timestamp: cron expressions are evaluated in the host's local timezone, while the recorded run time is stored in UTC. On a host set to anything other than UTC the two differ, so a task scheduled for midnight can show a run time a few hours off. Both are correct; they are just in different zones.