Docker Volumes vs Bind Mounts: Which Should You Use?

Quick answer

What this guide helps you do

Compare Docker-managed volumes and host bind mounts for home-server application data, media, portability, permissions, backups and recovery.

The short answer

Use a named volume when Docker should manage application data and the host path is not part of normal administration. Use a bind mount when a known host path must appear inside the container, such as a configuration file or media library. Neither choice creates a backup.

Quick comparison

Question	Named volume	Bind mount
Managed by Docker	Yes	No
Host path chosen by you	No	Yes
Easy to browse with host tools	Less direct	Yes
Depends on host layout	Less	More
Good for existing media	Usually not	Usually yes
Permission planning needed	Yes	Yes

Named volumes

services:
  database:
    image: postgres:17
    volumes:
      - database-data:/var/lib/postgresql/data
volumes:
  database-data:

Inspect with docker volume ls and docker volume inspect. Interact through a container or documented backup process; Docker warns against directly manipulating internal volume storage.

Bind mounts

services:
  app:
    volumes:
      - /srv/media:/media:ro
      - /srv/appdata/app:/config

Bind mounts make the host path explicit. They are useful for large existing libraries and administrator-managed configuration, but the same path and ownership must exist on another host.

Avoid the missing-drive trap

Before starting Docker, prove that external paths are mounted:

findmnt /srv/media
df -hT /srv/media

If the drive is absent, Docker may see an empty directory on the root filesystem. Arrange host mount ordering and monitoring.

Backups and security

Back up bind paths plus Compose files and secrets. Back up named volumes through an application-aware or temporary-container method. Quiesce or export databases consistently.

Expose only the narrowest host path. Prefer read-only access where possible. Mounting the Docker socket gives a container powerful control over the host.

Decision checklist

Persistent paths are documented.
External mounts exist before Docker starts.
Write access is minimal.
UID and GID behaviour is understood.
Databases have consistent backups.
Compose files and secrets are recoverable.
An isolated restore has succeeded.

This comparison is guidance, not a universal claim that one method is always better.

Next: How to Move Docker Data to Another Drive. Start with How to Install Docker on Ubuntu Server.

Official references: Docker volumes and bind mounts.

Search SmallGrid