Servers
Docker tab
Containers, images, volumes, networks and compose projects, without docker commands.
Docker packages an app and everything it needs into a container, so it runs
the same anywhere. If your developer mentioned Docker or you have a
docker-compose.yml file, your apps run this way.
If this tab says "Docker is not available on this server", Docker is not installed and you can ignore the tab. (There is a guided task to install it — see Guided tasks.)
Containers
The running (and stopped) copies of your apps.
| Column | Meaning |
|---|---|
| Name | What the container is called |
| Image | Which package it was built from |
| State | Running or stopped, plus warning badges — see below |
| Status | Up 3 days is good. Restarting over and over means it is crash-looping |
| Ports | How the outside world reaches it |
| CPU | 100% is one full core, so 150% means one and a half cores. The line under it is the container's CPU limit, or no limit |
| Mem | Memory in use, and the container's memory limit if it has one. The bar is measured against that limit, or against the whole server when there is none |
| I/O | Network received / sent, disk read / written, and how many processes it runs |
The header shows all containers together as a share of the whole server, for example 40% of 4 cores and 1.8 GB of 7.6 GB.
Badges worth acting on:
- unhealthy: the container's own health check is failing. It may still be running while it serves errors.
- OOM killed: it hit its memory limit and Docker killed it. Raise the limit (see below) or find what is using the memory.
- N restarts: Docker restarted it after a crash. A number that keeps growing means a crash loop. The reason is in the Logs.
Per container you can Start, Stop, Restart, Pause, read Logs (with Follow for live, Timestamps, a search box and Download), Open shell (a shell inside the container in the Terminal tab; needs Terminal access), and Inspect the full configuration. Remove asks first.
Limits
Limits caps how much memory and CPU one container can take, so a single runaway app cannot slow down everything else on the server. It also sets the restart policy: unless-stopped brings the container back after a crash or a reboot.
- Memory is a hard cap. A container that goes over it is killed and shows OOM killed.
- CPU is in cores (0.5 is half a core). A container at its limit slows down but keeps running.
The change applies straight away, with no restart. Docker can raise or lower a limit but cannot remove one; to run without a limit again, recreate the container. Containers created by Databases are sized from there instead, because the database's own memory settings have to match.
A container that keeps restarting is the most common Docker problem. Open its Logs — the reason is in the last lines before each restart.
Images
The templates containers are made from. Images are the usual cause of a mysteriously full disk: every build and every version you ever pulled stays until something removes it.
Prune deletes images nothing is using.
Pull image downloads an image by name (nginx:1.27,
ghcr.io/org/app:tag), or a newer build of a tag you already have. Running
containers keep the old build until they are recreated. This is safe for images, and the
space it frees is often tens of gigabytes.
Volumes
Where containers keep data that must survive being recreated — your database lives in one of these.
Deleting a volume deletes the data inside it, permanently. This is the one Docker action with no way back. The AI assistant always asks before removing a volume, even with auto-approve on.
Networks
How containers talk to each other. Rarely something you need to touch.
Compose
If your apps are defined in a docker-compose.yml, the compose projects appear
here and you can bring them Up or Down as a unit — which is usually
what you want, rather than restarting containers one by one.
Swarm services
If the server runs Docker Swarm, its services are listed and can be scaled — more or fewer replicas.
Disk usage and cleanup
df shows how much disk Docker is using, split by images, containers, volumes and build cache.
Prune is the cleanup. Safe order, most to least:
- Build cache — always safe.
- Unused images — safe. Usually the big win.
- Stopped containers — safe if you do not need their logs.
- Volumes — not safe. This is your data.
Recording
Every start, stop, restart, limit change, pull, prune and run is written to the Activity log.
Permissions
Operator and above can change things. Viewers see the lists, and cannot use Inspect for containers whose configuration includes environment variables, since those often hold passwords. See Roles.