Stage 4 · Provision
Running & Networking Containers
Volumes & Bind Mounts
Persist data with named volumes, bind source code, manage ownership, and clean unused storage.
Why Storage Matters
Container filesystems are ephemeral. When a container is removed, all data written to its writable layer is lost. For persistent data — databases, uploads, configuration — you need volumes or bind mounts that exist outside the container lifecycle.
Named Volumes
Named volumes are Docker-managed storage areas. Docker creates them on the host filesystem and manages their lifecycle. Named volumes persist after container removal, support driver-based storage backups, and are the recommended way to persist data.
# Create a named volume
docker volume create mydata
# Use the volume in a container
docker run -d \
-v mydata:/var/lib/postgresql/data \
--name db \
postgres:16-alpine
# The data persists after container removal
docker rm -f db
# Create a new container with the same volume
docker run -d \
-v mydata:/var/lib/postgresql/data \
--name db2 \
postgres:16-alpine
# Previous data is still thereNamed volumes are the safest way to persist data. Docker manages the storage location and handles ownership. The data survives container removal, host reboots, and Docker upgrades.
Bind Mounts
Bind mounts map a specific host path to a container path. Unlike named volumes, you control the exact location on the host. Bind mounts are essential for development — mounting your source code into a container enables live editing without rebuilding.
# Mount current directory into /app
docker run -v $(pwd):/app -w /app node:20-alpine npm start
# Read-only mount (container cannot modify host files)
docker run -v $(pwd)/config:/config:ro nginx
# Mount with specific ownership
docker run -v $(pwd)/data:/data:U myapp
# The :U flag creates a copy of the host directory
# with container user ownershipBind mounts use the host filesystem directly. Changes in the container are reflected on the host and vice versa. This is fast but less portable — the host path must exist.
Bind mounts give the container access to host files. A container with -v /:/host can read and write your entire filesystem. Use read-only mounts and specific paths to limit exposure.
tmpfs Mounts
tmpfs mounts store data in memory only. They are useful for sensitive data that should not persist to disk, or for high-speed temporary storage. The data is lost when the container stops.
# Mount a tmpfs with 100MB limit
docker run --tmpfs /tmp:rw,noexec,nosuid,size=100m myapp
# Use for sensitive data
docker run --tmpfs /run/secrets:rw,noexec myapp
# tmpfs is only available on Linux
# On Docker Desktop, it is emulatedtmpfs mounts are stored in RAM. They are fast and secure — no data reaches disk. Use them for temporary files, secrets, or any data that does not need to survive container restarts.
Ownership and Permissions
File ownership between host and container is a common source of bugs. The container runs as a specific user (often root), but files on the bind mount belong to the host user. This mismatch causes permission denied errors.
# Problem: container runs as root, files owned by host user
docker run -v $(pwd)/data:/data myapp
# Permission denied if container tries to write
# Solution 1: Use :U flag (remap ownership)
docker run -v $(pwd)/data:/data:U myapp
# Solution 2: Match the user ID
docker run --user $(id -u):$(id -g) -v $(pwd)/data:/data myapp
# Solution 3: Fix permissions in the Dockerfile
RUN chown -R appuser:appuser /dataThe :U flag tells Docker to adjust the volume ownership to match the container user. This is the simplest fix for bind mount permission issues.
Cleaning Up Storage
# List all volumes
docker volume ls
# Remove a specific volume
docker volume rm mydata
# Remove all unused volumes
docker volume prune
# Remove volumes with docker system prune
docker system prune --volumes
# Inspect volume details
docker volume inspect mydataUnused volumes consume disk space. docker volume prune removes volumes not referenced by any container. Be careful — this includes volumes you might want to keep for later use.
Never use bind mounts for database data in production. Named volumes provide better performance, easier backup, and Docker-managed lifecycle. Bind mounts can cause data corruption due to filesystem differences.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.