Containers are ephemeral by design — but your data shouldn't be. This lesson covers how Docker decouples storage from the container lifecycle so databases, uploads, and logs survive restarts and removals.

1. The Problem

Every container gets a thin writable layer on top of its image layers. When the container is removed, that layer is deleted — and all data written inside the container vanishes with it.

• Databases — PostgreSQL writes to /var/lib/postgresql/data. Remove the container? Gone.
• Uploads — User-uploaded files saved inside the container? Gone.
• Logs — Application logs written to /var/log/app? Gone.

There's also a performance problem: the writable layer uses a copy-on-write (CoW) filesystem. Every first write to a file copies it up from the image layer — adding latency. For I/O-heavy workloads like databases, this overhead is unacceptable.

2. Three Storage Options

Docker provides three mechanisms to persist or share data beyond the container lifecycle:

Type	Managed By	Location	Best For
Volume	Docker	/var/lib/docker/volumes/	Databases, persistent app data
Bind Mount	You (host path)	Anywhere on host	Dev hot-reload, config files
tmpfs	Kernel	RAM only	Secrets, temp processing

3. Volumes (Docker-Managed)

Volumes are the recommended way to persist data. Docker manages the storage directory — you reference volumes by name, not path.

# Create a named volume
docker volume create mydata

# Run a container with the volume mounted
docker run -d --name app1 -v mydata:/app/data alpine sh -c "echo hello > /app/data/test.txt"

# Another container can read the same data
docker run --rm -v mydata:/app/data alpine cat /app/data/test.txt
# Output: hello

Why volumes win:

• Work identically on Linux, macOS, and Windows
• Can be backed up, migrated, or pre-populated
• Support volume drivers for remote/cloud storage
• Safer — container can't accidentally traverse into host directories

4. Bind Mounts

Bind mounts map an exact host path into the container. The host directory must already exist.

# Mount current directory into container
docker run -d -v $(pwd):/app -w /app node:20-alpine npm run dev

# Changes on host instantly appear in container (hot-reload!)
# Changes in container instantly appear on host

Use cases:

• Development — edit code on host, app hot-reloads inside container
• Config injection — mount a single config file into the container
• Build output — container writes artifacts to a host directory

5. tmpfs Mounts

A tmpfs mount stores data in memory only. It is never written to the host filesystem, and disappears when the container stops.

# Mount tmpfs at /app/tmp (max 64MB)
docker run -d --tmpfs /app/tmp:size=64m myapp

# Or with --mount syntax
docker run -d --mount type=tmpfs,target=/app/tmp,tmpfs-size=67108864 myapp

Use cases:

• Storing short-lived secrets (tokens, session keys) that must never hit disk
• Scratch space for temporary processing (image manipulation, sorting)
• Fast I/O for ephemeral data — RAM is orders of magnitude faster than disk

6. Read-Only Mounts

Append :ro to make any mount read-only inside the container:

# Container can read config but cannot modify it
docker run -d -v ./nginx.conf:/etc/nginx/nginx.conf:ro nginx

# Volume mounted read-only
docker run -d -v mydata:/app/data:ro myapp

A common pattern: mount config/code as read-only, then add a tmpfs for any directory the app needs to write to temporarily:

docker run -d \
  -v ./app:/app:ro \
  --tmpfs /app/tmp \
  --tmpfs /tmp \
  myapp

This gives you immutable infrastructure — the container cannot modify its own code or config, reducing the blast radius of a compromise.

7. Volume Lifecycle & Cleanup

Volumes persist after container removal. This is by design — but it means orphaned volumes accumulate silently.

# List all volumes
docker volume ls

# Inspect a volume
docker volume inspect mydata

# Remove a specific volume
docker volume rm mydata

# Remove ALL unused volumes (not attached to any container)
docker volume prune

# Nuclear option: prune everything
docker system prune --volumes

Named vs Anonymous volumes:

• Named — -v mydata:/data — easy to identify and reuse
• Anonymous — -v /data (no name) — gets a random hash ID, hard to track, easy to orphan

8. Volume Drivers & Remote Storage

By default, volumes use the local driver (files on the host). Volume drivers extend this to remote and cloud storage:

• NFS — shared network filesystem for multi-host access
• AWS EBS — block storage in AWS (single-attach)
• Azure Files — SMB-based shared storage
• GlusterFS / Ceph — distributed storage clusters

# Create a volume using NFS driver
docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,rw \
  --opt device=:/shared \
  nfs-data

In Kubernetes, this concept is abstracted further with PersistentVolumes (PV) and PersistentVolumeClaims (PVC). You declare "I need 10GB of fast storage" and the cluster provisions it — no driver configuration in your container spec.

Interactive Quizzes

Hands-On Tasks

Key Takeaways

• Container writable layers are ephemeral — never store important data there
• Volumes are Docker-managed, portable, and the default choice for persistent data
• Bind mounts map host paths directly — great for development, risky for production
• tmpfs lives in RAM only — use for secrets and scratch data that must not persist
• :ro flag makes mounts read-only — defense in depth for config and code
• Volumes survive container removal — clean up with docker volume prune
• Always use named volumes — anonymous volumes become untrackable orphans
• Volume drivers extend storage to NFS, cloud, and distributed systems