Docker Storage Options: Named Volumes, Bind Mounts, and tmpfs Mount Mechanics

A production PostgreSQL container crashes due to a host kernel panic.

An automated monitoring script detects the failure, removes the failed container, and re-launches the service:

docker rm -f db-server
docker run -d --name db-server -e POSTGRES_PASSWORD=secret postgres:15

When web services reconnect, every single database table is gone.

The team discovers that PostgreSQL wrote its data files into /var/lib/postgresql/data inside the container’s ephemeral writable layer.

When docker rm deleted the container, it permanently erased the writable layer from host disk storage.

If the team had launched the container with a Named Volume:

docker run -d --name db-server -v pgdata:/var/lib/postgresql/data postgres:15

The database state would have survived container removal completely unharmed.

How do Docker’s three storage mechanisms—Named Volumes, Bind Mounts, and tmpfs Mounts—interact with the Linux Kernel Virtual File System (VFS)?

1. The Three Docker Storage Mechanisms

Docker provides three distinct options for persisting or isolating file data outside the container’s ephemeral OverlayFS writable layer:

                      +---------------------------------------+
                      |           HOST OS FILESYSTEM          |
                      +---------------------------------------+
                                          |
        +---------------------------------+---------------------------------+
        |                                 |                                 |
        v                                 v                                 v
[ 1. NAMED VOLUMES ]             [ 2. BIND MOUNTS ]               [ 3. TMPFS MOUNTS ]
- Managed by Docker Engine       - Direct user host path          - Stored in Host RAM
- Path: /var/lib/docker/         - Path: /home/user/app           - Never touches disk
  volumes/pgdata/_data           - Dev live-reloading             - Secrets & sensitive
- Lifecycle independent          - Host permission risk             in-memory caches

2. Named Volumes (`-v volume_name:/container/path`)

A Named Volume is a storage location created and fully managed by the Docker engine.

When you execute docker volume create pgdata, Docker creates a dedicated directory in the host filesystem:

/var/lib/docker/volumes/pgdata/_data

Key Mechanics of Named Volumes:

Lifecycle Independence: Named Volumes exist as first-class citizens in Docker. Deleting a container (docker rm) never deletes an attached Named Volume. The volume remains on disk until explicitly deleted via docker volume rm.
Volume Initialization Behavior: If you attach a brand new, empty Named Volume to a container directory that already contains files (e.g., -v empty_vol:/var/lib/mysql), Docker automatically copies the pre-existing container files into the volume during initial startup!
Driver Extensibility: Named Volumes support storage plugins (e.g., NFS, AWS EBS, Azure Disk), allowing volumes to mount remote network block storage.

3. Host Bind Mounts (`-v /host/path:/container/path`)

A Bind Mount maps an exact file or directory path from the host machine directly into the container’s mount namespace.

docker run -d -v $(pwd)/src:/app/src node:18-alpine

Key Mechanics of Bind Mounts:

Direct Kernel Passthrough: Executed via the mount --bind /host/path /container/path Linux system call.
Development Live Reloading: Any file edit made on the host (e.g., inside VS Code) is instantly visible inside the container without rebuilding the image.
No Automatic Initialization: Unlike Named Volumes, if you bind mount an empty host directory over a container directory containing files, the empty host directory masks the container directory.
Security Risks: Bind mounting sensitive host paths (like / or /var/run/docker.sock) into containers gives container processes root access to host filesystems.

4. `tmpfs` Mounts (`--tmpfs /container/path`)

A tmpfs Mount creates an in-memory filesystem stored exclusively in host RAM (or swap space).

docker run -d --tmpfs /tmp/cache my-app

Key Mechanics of `tmpfs` Mounts:

Zero Disk I/O Overhead: File operations execute at RAM speeds, bypassing physical storage devices.
Strict Security Posture: tmpfs files are never written to physical host disk storage or OverlayFS layers. When the container stops, the RAM allocation is reclaimed, leaving zero forensic trace on disk.
Use Cases: Storing transient encryption keys, API bearer tokens, or high-frequency in-memory caches.

Complete Storage Option Decision Matrix

Metric / Dimension	Ephemeral Layer	Named Volumes	Host Bind Mounts	`tmpfs` Mounts
Storage Location	OverlayFS (`upperdir`)	`/var/lib/docker/volumes/`	Any custom host directory	Host RAM Memory
Survives `docker rm`?	❌ No (Deleted)	✅ Yes	✅ Yes	❌ No (Erased on stop)
Performance	Copy-on-Write Penalty	Native Disk Speed	Native Disk Speed	RAM Speed
Host Directory Control	Docker Engine	Docker Engine	Developer Managed	Kernel Memory
Populates from Image?	N/A	✅ Yes (On initial creation)	❌ No (Masks target)	❌ No
Primary Use Case	Small transient files	Production DBs & Persistent Data	Local Code Development	Sensitive Secrets & Caches

Summary & Next Steps

Docker provides flexible storage abstractions for managing container state:

The Ephemeral Layer is deleted on container removal (docker rm), making it unsuitable for persistent data.
Named Volumes provide lifecycle-independent persistent storage managed by Docker.
Bind Mounts link host paths directly to containers, providing live-reloading capabilities for local development.
tmpfs Mounts store transient data exclusively in host RAM for maximum performance and security.

In the next article, we transition to Module 6 and explore Multi-Container Orchestration: Docker Compose Architecture and Declarative Configs.

References & Further Reading

National Institute of Standards and Technology (NIST). (2017). NIST SP 800-190: Application Container Security Guide. NIST Standard.
Linux Foundation. Software Package Data Exchange (SPDX) Specification v2.3. SPDX Standard.
Aqua Security. Trivy Vulnerability Scanner Architecture & Vulnerability Database. Trivy Docs.