Docker offers two main ways to persist and share data with containers — understanding when to use bind mounts versus named volumes helps you make the right choice for each specific use case.
Named Volumes
docker run -v myapp-data:/app/data myappDocker manages the actual storage location on the host, abstracted away from you — the volume has a name you reference, and Docker handles where it actually lives on the file system.
Bind Mounts
docker run -v /home/user/myapp/data:/app/data myappYou specify an exact host file system path, directly mapped into the container — you have full visibility and control over exactly where the data lives on the host.
Key Differences
| Factor | Named Volumes | Bind Mounts |
|---|---|---|
| Location control | Docker-managed, abstracted | You specify the exact host path |
| Portability | More portable across environments | Tied to specific host paths |
| Ease of direct host access | Less convenient (managed location) | Easy — just a regular directory |
| Common use case | Application/database data that Docker fully manages | Source code during development, configuration files |
When to Use Named Volumes
- Database data storage (most database images in this Knowledge Base use named volumes)
- Any data you want Docker to manage without needing direct host file system access
- Production deployments where volume portability matters
When to Use Bind Mounts
- Mounting source code during development (live-reload workflows)
- Mounting configuration files you want to edit directly on the host
- When you need the data at a specific, known host location for other tooling (backup scripts, direct inspection)
Development Example: Live Code Reloading with Bind Mounts
services:
app:
build: .
volumes:
- ./src:/app/src
command: npm run devChanges to your local source code immediately reflect inside the running container, ideal for active development.
Production Example: Database Data with Named Volumes
services:
db:
image: postgres:16
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:Finding Where a Named Volume Actually Lives
docker volume inspect postgres-dataShows the actual host path Docker is using, though you generally shouldn't need to interact with this directly given the named volume abstraction.
Backing Up Each Type
Named volumes: use a temporary container to tar the volume contents (see backup examples throughout this Knowledge Base's Docker-based application guides). Bind mounts: back up the known host directory directly using standard file system backup tools.
A Practical Rule of Thumb
Use named volumes for anything Docker should fully own and manage (database storage, application state); use bind mounts when you specifically need direct host-level visibility or editing access to the data.
Common Errors
Bind mount shows empty/wrong content — verify the host path is correct and actually exists; a typo in the path silently creates an empty directory rather than erroring, a common source of confusion.
Continue Reading
- Docker Volumes: How to Persist Data Beyond a Container's Lifecycle
- How to Install Docker Compose on Ubuntu & Debian
- How to Set Up Automated VPS Backups
Browse more articles in Docker & Containers.
