Why are named volumes generally preferred over bind mounts in production?

Portability across hosts and environments

# Bind mount: hardcodes a specific host path -- this exact path must exist,
# with correct permissions, on EVERY machine this container might ever run on
docker run -v /opt/myapp/data:/app/data myapp

# Named volume: portable -- Docker manages where it actually lives,
# and the SAME command works identically regardless of host layout
docker run -v app-data:/app/data myapp

A bind mount's correctness depends on the assumption that /opt/myapp/data exists, with the right permissions, on whatever host this container happens to run on. That assumption breaks the moment you deploy to a different server, a different developer's laptop, or a freshly provisioned machine without that exact directory structure already set up. A named volume has no such dependency. Docker creates and manages it consistently regardless of the host's own directory layout. This is precisely the same portability guarantee containers are meant to provide for application code in the first place (see the fundamentals topic).

Consistent tooling and lifecycle management

docker volume ls
docker volume inspect app-data
docker volume prune            # clean up unused volumes

Docker's own CLI and API provide first-class commands for listing, inspecting, and cleaning up volumes. A bind mount, being just an arbitrary host directory, isn't tracked or managed by Docker at all in the same way. You must figure out yourself what host directories are actually being used by which containers. Cleaning them up requires ordinary filesystem tools, rather than Docker's own consistent volume-management commands.

Volume drivers extend capability without changing application configuration

docker volume create --driver local --opt type=nfs --opt device=:/exported/path --opt o=addr=nfs-server.example.com my-nfs-volume

Named volumes support pluggable volume drivers (see that question). This lets the same -v my-nfs-volume:/app/data reference in a container's configuration be backed by local disk, NFS, a cloud storage service, or another storage backend entirely. The underlying storage implementation can be swapped without touching the container's own configuration at all. A bind mount, by definition, is always tied to whatever's actually at that literal host path. There is no equivalent abstraction layer to swap the backing storage transparently.

Permission and ownership complications specific to bind mounts

Bind mounts frequently run into UID/GID mismatch issues. A container process running as a specific user ID needs to actually have permission to read and write the bound host directory. Host-side and container-side user ID mappings don't always align cleanly, especially across different host operating systems, or when a container's internal user doesn't correspond to any real user on the host. Named volumes, being fully managed by Docker, avoid much of this complexity, since Docker handles the underlying storage directly rather than requiring alignment with an arbitrary host directory's existing ownership.

When bind mounts are still the right, deliberate choice

• Local development — live-mounting your actual source code directory into a container so code changes are immediately reflected without rebuilding the image, a very common and appropriate development workflow.
• Deliberately sharing a specific, known host resource — e.g., mounting /etc/localtime read-only to sync a container's timezone with the host's, or mounting a Unix socket like the Docker socket itself (with the security caveats covered in that topic's question).

Reaching for a bind mount purely out of habit, rather than for one of these deliberate reasons, is usually a sign the default should have been a named volume instead.