Volumes

Volumes persist data outside the container writable layer. Use them for local databases, uploaded files in development, package caches, or generated artifacts — but design production persistence with backup, ownership, and lifecycle explicitly.

| Type | Typical use | |------|-------------| | Named volume | Docker-managed storage, portable across hosts | | Bind mount | Mount host path for fast local dev iteration | | tmpfs | Ephemeral in-memory data |

					# compose excerpt
services:
  postgres:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:
				

On interviews: bind mount vs named volume, cleanup on `docker compose down -v`, and why production databases usually live outside ad-hoc container volumes.

Common pitfalls: bind mounts hide image files unpredictably; anonymous volumes survive longer than expected; no backup plan for "temporary" dev data that becomes important.

The trade-off is developer velocity (bind mounts) versus portability and predictable production storage.

Checklist:

• Choose bind mount or named volume deliberately.
• Document cleanup commands.
• Back up durable data with ownership clarity.
• Do not treat container layer as a database.