Volumes

Understand Docker volumes and bind mounts for persistent data, local development, backups, and production storage boundaries.

Last reviewed: June 2026

·Docker Engine 24+Docker Desktop 4+Docker Compose v2
✅
Quick Understanding: Containers are disposable, so data written inside the container layer disappears when the container is removed. Volumes store data outside the container lifecycle.

🔍 What Is It?

Docker volumes are persistent storage managed by Docker.

There are two common mount styles:

  • →Named volumes - Docker-managed storage, good for databases and persistent local data
  • →Bind mounts - host paths mounted into containers, common for local development

Volumes decouple data from containers.

🎯 Why Do We Need It?

Containers should be replaceable. Databases, uploads, queues, and generated files often need data to survive container replacement.

Volumes solve that local persistence problem and make development workflows smoother.

🏗️ What Happens in Real Projects?

Developers commonly use volumes for local Postgres, MySQL, Redis, Elasticsearch, and uploaded test files.

In production, teams often prefer managed databases and object storage instead of relying on single-host Docker volumes. If volumes are used in production, backup, scheduling, and host failure behavior must be designed explicitly.

⚙️ How It Works

When a volume is mounted into a container path, writes to that path go to the volume rather than the container writable layer.

Example:

-v postgres_data:/var/lib/postgresql/data

The container can be removed and recreated while the named volume remains.

💻 Example

Persisting Database Data — A named volume keeps Postgres data after the container is recreated.

bash
docker volume create postgres_data

docker run -d --name postgres \
  -e POSTGRES_PASSWORD=secret \
  -v postgres_data:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

🤔 Common Confusions

❓ Is a volume inside the image?

No. A volume is mounted at runtime and exists outside the image.

❓ What is the difference between a volume and a bind mount?

A named volume is managed by Docker. A bind mount maps a specific host path into the container.

❓ Why did my data disappear?

It was probably written to the container writable layer instead of a mounted volume or external storage.

🚨 Common Production Issues

**No backups** - teams persist data in volumes but do not back it up.

**Host coupling** - data is tied to one machine and cannot move during failover.

**Permission mismatch** - container users cannot read or write mounted files.

**Bind mount surprises** - host directory contents hide files that were present in the image path.

✅ Best Practices

Use named volumes for local persistent service data

Use bind mounts mainly for local development workflows

Prefer managed databases or platform storage for production state

Document backup and restore procedures for persistent volumes

Run containers with predictable user IDs when mounting host files

Do not store secrets in casual host-mounted folders

🏛️ Architect's Note

Senior Architect's Perspective

Docker makes containers disposable, but it does not make state disappear as an architectural concern.

For production, ask where state lives, how it is backed up, who owns restore testing, and what happens when the host dies. Volumes are a mechanism, not a data strategy.

💬 Frequently Asked Questions

Do volumes get deleted with containers?

Named volumes normally remain after containers are removed unless explicitly deleted.

Can multiple containers share a volume?

Yes, but concurrent writes must be safe for the application and storage driver.

Where are Docker volumes stored?

Docker stores named volumes in its managed data area on the host. The exact path depends on the platform.

🎯 Key Takeaways

1Container writable layers are disposable
2Volumes persist data outside container lifecycle
3Named volumes are Docker-managed
4Bind mounts map host paths
5Production storage needs backup and failover planning

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Docker references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages