Volume Drivers and Remote Storage

Every volume has a driver, and by default it's local — storage on this host's disk under /var/lib/docker/volumes. Swap the driver and a volume can be backed by something else: an NFS export, a cloud block device, or a plugin-provided backend, all behind the same docker volume interface the application never sees. On a single host that's useful for putting data on a specific disk or a network share.

The moment you need the same volume on many hosts at once, though, you've crossed a line a driver flag can't take you over. Coordinated, schedulable storage across hosts is a scheduling problem, not a storage option — and that's where orchestration takes over. This book stops at the single-host volume; the multi-host case waits for Kubernetes in chapter 12.

The Local Driver Is the Default

Every named volume is local unless you tell Docker otherwise, storing its data on this host's filesystem. docker volume inspect driftwood-db-data shows the driver and the mountpoint, and for the single-host Driftwood setup that's the correct and complete answer — the database's data lives on the machine's own disk, managed by Docker, and nothing more is needed. Most production single-host deployments never move off local, and they're right not to.

Driver Options on the Local Driver

The local driver itself accepts options that change where the bytes actually land. You can point a volume at an NFS export or a specific block device, so the volume's backing store is a network share or a dedicated disk while it still presents to the container as an ordinary Docker volume. The application mounts a path; it has no idea the path is really an NFS server across the room.

docker volume create --driver local \
  --opt type=nfs \
  --opt o=addr=10.0.0.20,rw \
  --opt device=:/exports/driftwood \
  driftwood-nfs-data

docker run -d --name driftwood-db \
  -v driftwood-nfs-data:/var/lib/postgresql/data \
  postgres:16

The volume is still created and mounted with the same commands as any other, but its data now lives on the NFS server at 10.0.0.20 rather than the local disk. From the container's side nothing changed — it sees a directory at /var/lib/postgresql/data — which is exactly the point: the storage backend stays invisible to the image.

Plugin Drivers

Installed volume plugins add drivers beyond local, attaching cloud block storage or a networked filesystem as a volume. The plugin handles the durability and replication of the backend; the container still just sees a mounted path. This is how a single host can put a volume on a managed disk that the cloud provider keeps redundant copies of, without the application knowing or caring where the bytes physically sit.

The Single-Host Boundary

These drivers can put one host's volume on remote storage, but giving several hosts coordinated, schedulable access to shared data is a different problem. Deciding which host runs a workload, attaching the right storage to it, and detaching it cleanly when the workload moves — that's scheduling, not a storage flag. It's where orchestration and CSI (Container Storage Interface) drivers take over, covered in chapter 12. A Docker volume driver gives one host remote bytes; it does not coordinate many hosts around shared bytes, and stretching it to try is where the trouble starts.

When a Remote Driver Earns Its Place

Reach past local for one of two concrete reasons: the data must survive the host itself — a managed disk that outlives the machine it's attached to — or it has to live on storage that already exists, like an NFS server other systems also use. Absent those, a local volume with a real backup plan (topic 38) is simpler, faster, and has fewer moving parts than a network-backed volume. Don't add a remote driver to chase resilience you can get more cheaply from backups.