Docker¶

Docker recipes organised into submodules that mirror the Docker CLI. Run just docker for the dashboard, then drill into submodules as needed.

Submodules¶

Interactive Mode (-i)¶

Most recipes that target a service or container accept -i for interactive selection via fzf. The scope depends on the module:

• compose recipes pick from services defined in the Compose file
• container recipes pick from running containers system-wide
• image/network recipes pick from all images or networks

just docker compose logs -i          # pick service(s) from compose file
just docker container shell -i       # pick from running containers
just docker image rm -i              # pick from all images

You can always pass names directly instead of using -i:

just docker compose restart web api  # restart specific services
just docker container logs myapp     # tail a specific container

Service Targeting (Compose)¶

Compose lifecycle recipes accept optional service names. No args means all services; named args target only those:

just docker compose up               # start all services
just docker compose up web worker    # start only web and worker
just docker compose stop -i          # pick which to pause
just docker compose rebuild web      # fresh rebuild of one service

Day-to-Day Workflows¶

Start working on a project: cd ~/project && just docker compose up then just docker compose logs -i to pick a service and watch output.

Bounce a broken service: just docker compose restart web or just docker compose restart -i to pick.

Take a break, come back later: just docker compose stop pauses containers without removing anything. Resume with just docker compose start. State (tmpfs, anonymous volumes) is preserved.

Done for the day: just docker compose down stops and removes containers and networks. Next up recreates everything from the Compose file. Named volumes are kept.

Tear down and rebuild one service: just docker compose rebuild web stops, removes, builds fresh (no cache), and starts the service. For a full project reset including images: just docker compose reset.

Inspect a running container: just docker container shell -i picks a container and opens a shell (defaults to sh, pass -s bash for bash). Works from any directory — not project-scoped.

Logs getting too big or noisy: just docker container clear-logs -i truncates the log file on disk without restarting. Requires sudo because Docker owns the log files.

Disk Recovery¶

When Docker is eating disk, escalate in this order:

1. just docker disk — see what's using space
2. just docker image prune — remove unused images
3. just docker sys prune — remove unused images, networks, build cache, and anonymous volumes
4. just docker sys nuke — kill all containers and remove everything. Last resort. Requires confirmation.

Both prune and nuke preserve named volumes.

Volumes¶

Named volumes are never removed automatically by any recipe. They contain persistent data (databases, application state) that cannot be recovered.

just docker volume rm is the only path to removal. Use -i for interactive selection (project-scoped if in a Compose directory, requires fzf) or pass volume names directly: just docker volume rm my_volume.

System-Wide Operations¶

Everything under just docker sys affects the entire Docker host and requires confirmation.

sys stop gives containers 10 seconds to shut down gracefully (SIGTERM then SIGKILL). sys kill sends SIGKILL immediately — use this when containers are hung or unresponsive.

sys prune removes all unused resources but leaves running containers alone. sys nuke kills everything first, then prunes. Both preserve named volumes — use just docker volume rm to deal with those separately.

Gotchas¶

• Compose recipes fail if there's no Compose file. This is intentional — they never silently fall through to system-wide scope.
• stop and down mean different things: stop pauses (resume with start), down removes (recreate with up).
• reset removes all project images. Next up will be slow as everything gets pulled/built again.
• rebuild requires a target — specify service(s) or use -i. Use reset for a full project teardown.
• -i requires fzf. If not installed, pass names directly.
• sys nuke is genuinely dangerous in production. It's designed for development environments where Docker has got into a bad state.