Skip to main content
How do you persist the data a container produces? Containers are ephemeral by design: when a container is removed, anything stored only inside it is lost. To persist data reliably you must place it outside the container’s writable layer. Two common approaches are bind mounts and named volumes. Choosing the right one affects development workflow, portability, and production reliability. Below we compare both approaches, explain typical use cases, and show simple examples.

​
Option 1 — Bind mounts (host directory mounted into container)

With a bind mount you attach a specific folder on the host into the container. Anything written by the container to that mount goes directly into the host folder. This is convenient for local development because you can edit code on your machine and the running container immediately sees those changes.
The image explains "Bind Mounts" with a diagram showing a connection between a host machine and a container, emphasizing local development where code edits are instantly reflected in the container.
Example: mount a host directory into the container
Drawbacks of bind mounts in production:
  • You must ensure the same host path exists on every node in your cluster.
  • Permissions and ownership on each host must be configured correctly.
  • Coordination across hosts becomes operationally expensive and error-prone.
The image shows three machines with boxes and their data folder statuses: Machine 1 and Machine 2 have /data, while Machine 3 does not. It emphasizes the need for every host to have the same /data.
In short: bind mounts are excellent for local development and quick iterations, but they can be fragile and difficult to manage across multiple production hosts.

​
Option 2 — Named volumes (Docker-managed volumes)

Named volumes are managed by Docker. When you use a named volume Docker creates and controls the directory on the host (typically under Docker’s volumes directory, such as /var/lib/docker/volumes), and exposes it to containers. You reference volumes by name and Docker handles the location and permissions.
The image illustrates the "Named Volumes" option in Docker architecture, showing the relationship between Docker, the host disk, and a container.
Example: create and attach a named volume for MySQL
How this behaves:
  • The first time you run the command Docker will create the dbdata volume automatically.
  • On subsequent runs you can reuse dbdata to attach the same persistent data to a new container.
  • If the container is removed, the volume remains on disk and can be re-attached to other containers.
The image illustrates how Docker manages data persistence, showing that when a container dies, the volume remains intact.
Important production note:
  • Named volumes are local to the Docker host where they are created. To share data across multiple hosts you need a volume driver or network-backed storage (NFS, cloud block storage like AWS EBS, Azure Disk, or a distributed filesystem such as GlusterFS or Ceph) that provides a shared backing store.
The image compares "Bind Mount" with "Named Volume" in Docker, highlighting that with Bind Mount, you manage the host path and permissions, while with Named Volume, Docker owns it and ensures consistency.

​
Quick comparison

​
When to use which

  • Use bind mounts:
    • For development workflows where editing files on the host should reflect immediately inside the container.
    • When you need to expose specific host files (e.g., SSH keys, host config files).
  • Use named volumes:
    • For production data that must survive container recreation.
    • When you want Docker to manage storage location and permissions.
    • When integrating with Docker volume drivers or cloud block storage for multi-host persistence.
For more details, see the official Docker documentation: https://docs.docker.com/storage/volumes/
Use bind mounts for local development when you need immediate file sync with the host. Use named volumes in production to let Docker manage the host storage path and permissions, ensuring consistent, portable data persistence.

Watch Video