## Reclaim the space now

```bash
ssh your-server 'df -h /'
ssh your-server 'docker image prune -a -f'
ssh your-server 'docker system df'
```

`docker system df` is the one worth reading: it separates images, containers, volumes and build
cache, so you can see which one actually grew. On a deploy host the answer is almost always images.

Be deliberate about `-a`. It removes every image not currently used by a running container, which
includes the previous release you would roll back to. Prune when you are happy with what is live,
not in the middle of an incident.

## Why it fills up

Each deploy builds an image, pushes it to the registry, and pulls it on the server. The old image
stays: that is what makes a rollback instant. Nothing removes it on a schedule. At roughly 400MB per
image, a small VPS runs out somewhere between thirty and sixty deploys, and the symptom is a deploy
that fails at the pull step with no obvious connection to disk.

## Stop it recurring

Set a retention limit on the Docker daemon so it prunes as it goes:

```bash
ssh your-server 'cat /etc/docker/daemon.json'
```

```json
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }
```

Container logs are the second thing that fills a disk, and unlike images nothing rotates them by
default. The setting above caps each container at 30MB.

## What this does not cover

SQLite. If `df -h` shows the disk full and pruning reclaims nothing, look at the database volume and
at `storage` for uploaded files, which grow with real use rather than with deploys. The volume
mounts are declared in `config/deploy.yml`, so that file tells you which host directories to size.
See
[Production Database and Storage](/docs/deployment/production-database-and-storage) for where those
live and how to size them.