What's the difference between a volume, a bind mount, and tmpfs?
Quick Answer
A volume is storage fully managed by Docker itself, living in Docker's own managed area on disk, independent of any specific host directory structure — the standard, recommended choice for persisting real application data. A bind mount maps an arbitrary, specific path on the host's filesystem directly into the container — full control over exactly where the data lives on the host, but tightly coupled to that host's specific directory layout. A tmpfs mount stores data only in the host's memory (RAM), never touching disk at all — fast, but the data is gone the moment the container stops.
Detailed Answer
Volumes — Docker-managed, the recommended default
docker volume create my-data
docker run -d -v my-data:/app/data myapp:1.0
Docker creates and manages the actual storage location on the host's filesystem (typically under /var/lib/docker/volumes/), completely abstracted away from you. You reference it by name (my-data), not by a specific host path. Volumes are the recommended mechanism for persisting any real application data (a database's files, uploaded content). This is precisely because Docker manages their lifecycle, backup tooling, and driver options consistently, independent of the host's own directory structure.
Bind mounts — an arbitrary host path, mapped directly in
docker run -d -v /home/user/my-config:/app/config myapp:1.0
# or, using the more explicit --mount syntax:
docker run -d --mount type=bind,source=/home/user/my-config,target=/app/config myapp:1.0
Maps a specific, existing path on the host directly into the container. This gives full transparency and control over exactly where the data lives on the host's own filesystem, which is genuinely useful for specific scenarios: mounting your local source code directory into a container for live-reload development, or sharing a specific existing host directory. The tradeoff is that the container's behavior now depends on that exact host path existing and having the right permissions and content. This tightly couples the container to that specific host's directory layout, in a way that hurts portability across different machines and environments.
tmpfs mounts — memory-only, never touches disk
docker run -d --tmpfs /app/cache myapp:1.0
Data written here lives entirely in the host's RAM. This is extremely fast, but it is completely lost the moment the container stops. This isn't just on removal — even a docker stop/docker start cycle loses it, unlike a volume or bind mount. This is useful for genuinely temporary data that is sensitive to persist: a cache that's fine to lose, or explicitly avoiding writing sensitive temporary data (like a decrypted secret) to disk at all, even transiently.
Side-by-side comparison
| Volume | Bind mount | tmpfs | |
|---|---|---|---|
| Managed by | Docker | You (an arbitrary host path) | Docker (in-memory only) |
| Survives container removal | Yes | Yes (it's just a host directory) | No — gone even on container stop |
| Portable across different hosts | Yes (referenced by name, not host path) | No (tied to that host's specific path) | N/A (never persists anywhere) |
| Typical use | Real application/database data | Local development (mounting source code), sharing a specific existing host resource | Temporary, sensitive, or performance-critical scratch data |
Why volumes are generally preferred over bind mounts in production
Recall that a bind mount ties the container's correct behavior to the specific host's directory structure and permissions. This is exactly the kind of environment-dependent coupling containers are meant to eliminate (see the fundamentals topic's "what problem does Docker solve" question). A volume, referenced purely by name, works identically regardless of which host it's actually running on, or how that host's filesystem happens to be laid out. This is a meaningfully better fit for production deployments, where you want the same container configuration to behave identically across different machines.