iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use a Docker-managed volume for persistent application data that should outlive a container; use a bind mount when the container and host need to access the same specific files or directory. In this step-by-step guide, you’ll choose a mount based on who owns the data, run it with Docker’s explicit --mount syntax, and verify what the container can see.
Docker volumes vs. bind mounts: what’s the difference?
Both volumes and bind mounts make data available at a path inside a container. The difference is who chooses and manages the storage location: Docker manages a volume’s location, while a bind mount maps a path you choose on the Docker daemon’s host.
| Decision | Docker-managed volume | Bind mount |
|---|---|---|
| Who selects the source location? | Docker manages it. | You specify a host file or directory path. |
| Typical fit | Persistent application or database data; data shared among containers. | Source code, configuration, build artifacts, or output that must be shared with the host. |
| Portability | Less dependent on a particular host directory layout. | Depends on the host path and Docker daemon environment. |
| Host access | Docker-managed; directly manipulating volume files on the host is not the usual workflow. | The specified host path is intentionally shared. |
| Main caution | The volume has a separate lifecycle and remains after its container is removed. | Read-write by default; a mount can change host files and obscure existing files at its container destination. |
Docker describes volumes as its preferred mechanism for persisting data generated by and used by containers. Docker’s volumes documentation explains their lifecycle and management. For a bind mount, Docker’s bind-mount documentation describes mounting a host file or directory into a container.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Which should you choose?
Choose a named volume for application state
Use a named volume by default for database files, uploads, or other application state that needs to survive container replacement but does not need to live in a specific project directory on the host. Docker manages the source location, and you can attach the same volume to another container when needed.
#1 Best Overall
Choose a bind mount for files shared with the host
Use a bind mount when you want edits or generated files to appear at a particular host path—for example, a development source tree mounted at /app. It is also appropriate when an application needs a specific host configuration file. The selected path must be available on the machine running the Docker daemon.
Use neither for temporary in-memory data
If data should be kept in memory and not persisted after a container stops or restarts, Docker’s tmpfs mount is another option on supported Linux environments. It is not a substitute for persistent storage. See Docker’s storage overview.
Do not rely on the container’s writable layer for persistence
Data written only to a container’s writable layer is lost when that container is destroyed. Put data that must remain in a volume or bind mount instead. Persistence alone does not make a backup.
Rank #2
Step 1: Identify the data and its destination
Decide whether the data belongs to the application or must be shared with a particular host location. Then choose the path inside the container where the application expects to read or write it, such as /var/lib/app or /app. The container destination must be an absolute path. Docker documents the run options and mount syntax in its container run reference.
Step 2: Create and use a named volume
- Create a volume named
app-data:docker volume create app-data - Run the image with that volume mounted at the application’s data path:
docker run --name app \ --mount type=volume,src=app-data,dst=/var/lib/app \ IMAGEReplace
IMAGEwith the image name you intend to run. Docker can also create a missing named volume when the container starts.
Removing the container does not remove app-data. Volume removal is a separate action, which lets the data remain available to a replacement container.
Step 3: Share a host directory with a bind mount
From the project directory, mount the current directory at /app:
Rank #3
docker run --name dev \
--mount type=bind,src="$(pwd)",dst=/app \
IMAGEThis example uses shell syntax that works in common Unix-like shells; path handling differs across operating systems and Docker Desktop setups. Docker resolves a bind source on the daemon host, not necessarily on the machine where the Docker CLI is running. In a remote-daemon setup, a path local to your CLI machine is not automatically available to the daemon.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →If the container only needs to read the project files, make the bind mount read-only:
docker run --name dev \
--mount type=bind,src="$(pwd)",dst=/app,readonly \
IMAGEBind mounts are read-write unless you specify otherwise. A process in the container can therefore modify or delete files at the host path when the mount is writable.
Step 4: Verify the mount
Inspect the container and check its Mounts section for the source, destination, and mount type:
docker inspect appFor the named-volume example, confirm the type is volume, the destination is /var/lib/app, and the source refers to app-data. For a bind mount, check that the source is the intended host path and the destination matches the container path you chose.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesStep 5: Avoid common mount mistakes
- Mounting over existing container files: A bind mount placed over a non-empty directory obscures that directory’s original contents while the mount is present. Choose a destination that is meant to be replaced or inspect the image’s directory contents first.
- Typos in bind sources: With
--mount type=bind, Docker normally reports an error if the source path does not exist. Itsbind-create-srcoption can create the source directory. By contrast, the shorthand-vor--volumesyntax creates a missing host source path as a directory, which can conceal a typo. Prefer the explicit--mountform when you want a missing source to fail clearly. - Unintended host changes: Bind mounts are writable by default. Use
readonlywhen the container only needs to read files, and avoid mounting sensitive host paths unless access is necessary. - Deleting persistent data while cleaning up: Removing a container and removing its named volume are separate operations.
docker volume pruneremoves unused volumes, so check that an unused volume does not contain data you still need before pruning.
Docker’s storage documentation makes qualitative distinctions between storage types, but it does not establish a universal performance winner between volumes and bind mounts across host platforms and workloads. Choose based on data ownership and host-sharing needs rather than an assumed speed advantage.
Best Value
- Docker, Docker Swarm, Docker Compose, Programmer, Developer, Coding, Programming, Software Engineer, Code, DevOps, Deploy, Deployment, Kubernetes, Salt, Puppet, Chef, Terraform, Container, AWS, Azure, Cloud, Geek, Funny, Computer, Software, Tech, IT
- Integration, Scrum, Compile, Compilation, Science, Bug, Debug, Python, Linux, Java, Javascript, Scala, Dotnet, Kotlin
- Lightweight, Classic fit, Double-needle sleeve and bottom hem
Use a named volume in Docker Compose
In Compose, declare a named volume at the top level and attach it to the service that needs it. A bind mount instead specifies a host path and a container target. A volume shared by multiple services must be listed under each service that uses it. See Docker’s Compose volume reference.
services:
app:
image: IMAGE
volumes:
- app-data:/var/lib/app
volumes:
app-data:For a host directory, use a host path and target in the service’s volumes list, for example ./src:/app. Add a read-only setting if the service should not write to that directory.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
