How do volume drivers extend Docker's storage capabilities?
Quick Answer
A volume driver is a pluggable backend that decides where and how a named volume's data is stored. The default local driver just uses a directory on the host's own disk, but third-party and cloud-provider drivers can back a volume with NFS, cloud block/object storage, or other distributed storage — while the container itself still just references the volume by name with the same -v/--mount syntax. This lets the same container configuration work with very different storage infrastructure underneath, without the application needing to know or care which one is in use.
Detailed Answer
The default: the local driver
docker volume create my-data
docker volume inspect my-data
# "Driver": "local"
# "Mountpoint": "/var/lib/docker/volumes/my-data/_data"
Without specifying a driver, Docker uses the built-in local driver, which just creates and manages a directory on the host's own disk. That's fine for single-host setups, but it means the volume's data is physically tied to that one host — if the container needs to move to a different machine, the volume and its data don't automatically come along.
Using an alternative volume driver
docker volume create --driver local \
--opt type=nfs \
--opt o=addr=192.168.1.100,rw \
--opt device=:/exported/path \
my-nfs-volume
docker run -d -v my-nfs-volume:/app/data myapp:1.0
This example uses the local driver's built-in NFS support, backing the "volume" with a remote NFS share instead of local disk. The container's own configuration, -v my-nfs-volume:/app/data, looks identical to using a plain local volume — only the volume's creation-time definition differs.
Third-party volume driver plugins extend this further, supporting cloud block storage, distributed storage systems like Ceph and GlusterFS, and other backends. Each implements Docker's volume plugin API, so from the container's perspective, using them needs no different syntax than any other named volume.
Why this abstraction matters
Container's perspective: -v my-data:/app/data (identical, regardless of backend)
Actual backend, depending on the driver used:
- local disk (default "local" driver)
- NFS share
- Cloud block storage (via a cloud-specific driver)
- A distributed storage system
This mirrors the same abstraction philosophy behind Kubernetes's StorageClasses and the Container Storage Interface (CSI). Application/container config references storage in an abstract, backend-agnostic way, while a pluggable driver layer handles the actual implementation underneath. The benefit is the same in both ecosystems: you can change or upgrade the underlying storage without rewriting every container's configuration.
When you'd actually reach for a non-default driver
- Multi-host setups without a full orchestrator — if you're running plain Docker (not Swarm or Kubernetes) across multiple hosts, and need a container's data accessible regardless of which host it runs on, a network-backed volume driver like NFS or a distributed storage plugin solves this. The default
localdriver's host-tied storage can't. - Cloud-native storage integration — using a cloud provider's own volume driver plugin to back Docker volumes with that provider's managed block/file storage, gaining its durability, snapshotting, and replication features.
For simple, single-host Docker deployments, the default local driver is entirely sufficient and needs no extra configuration.