OPERATING

Docker resources and disk

Inspect the containers, images, networks and volumes on a host, and reclaim the disk they leak.

Under every application the panel deploys sit ordinary Docker objects: containers, images, networks and volumes. Docker in the sidebar shows them as the daemon actually reports them, per server, and lets you act on the ones that are yours to act on.

This page is platform-admin only, on every install. It shows *every* container on the host, including the panel’s own database and proxy — there is no project-scoped version of it, and no API key can reach it.

What the four tabs show

Containers: Every container on the selected server, with its image, ports, status and uptime. Start, stop and restart are here — this is the view for a container that exists on the host but is not one of your applications.
Images: Pulled and built images with their tags and size. This is where disk goes: every rebuild leaves the previous image behind, tagged or dangling.
Networks: Docker networks with their driver and scope, including the per-project network the panel creates for you.
Volumes: Named volumes with their driver and mountpoint. A volume outlives the container that made it — that is the point, and also why an unused one is easy to forget.

On a multi-server install, the server switcher at the top of the page picks which daemon you are looking at. Docker objects are per-host: an image present on one server is not present on another until something pulls or builds it there.

Why some rows have no delete button

Rows badged system are the panel’s own control plane — the API, the dashboard, PostgreSQL, Redis, the reverse proxy and the agent — plus the predefined Docker networks (bridge, host, none) and the volumes holding the panel’s data.

The refusal is enforced by the server, not by the hidden button. Calling the delete endpoint directly with a hex ID instead of a name is refused too: the identifier is resolved back to a name and re-checked. And if the daemon cannot be reached to resolve it, the action is refused rather than attempted — a stopped container is a nuisance, a stopped control plane is an outage you cannot log in to fix.

To update the panel itself, use Admin → Updates, which pulls the new image and restarts the stack in the right order. Restarting dockboard-api by hand from this page is not the same operation.

Reclaiming disk

A host that fills up usually fills up for one of three reasons, and Prune offers exactly those three:

Target	Removes	Costs you
Dangling images	Untagged layers left behind by rebuilds — nothing references them.	Nothing.
Unused networks	Networks with no container attached. Project networks in use are untouched.	Nothing.
Build cache	The BuildKit cache, which only ever grows.	The next build of each application is slower — once.

There is deliberately no volume prune. Docker considers a volume unused as soon as no container is attached, which is true of every stopped application — a volume prune would delete their data. Volumes are removed one at a time, by name, after you have decided the data is expendable.

You rarely need to run this by hand: the nightly cleanup does the same work at 03:00 UTC and is on by default. Reach for the button when a build has just failed for lack of space and you do not want to wait for tonight.

When to come here at all

For anything that belongs to an application — restarting it, reading its logs, opening a shell — use the application itself. Its page knows what the container is *for*, and acting there keeps the panel’s idea of the state and Docker’s in agreement.

A container is running on the host that no application accounts for — left by a manual docker run, or by a stack the panel no longer tracks.
Disk is filling up and you want to see which images and volumes are actually holding it.
A deploy failed halfway and you want to confirm what the daemon really has, rather than what the panel believes it has.
A volume survived an application you deleted, and you have decided its data is no longer needed.

Every destructive action here is written to the audit trail with the object it targeted and who asked for it — including the ones the server refused.