Before the technical detail, let’s establish the core idea clearly.

A Docker volume, as covered elsewhere, is Docker’s own self-managed way of giving a container persistent storage that survives beyond that container’s own lifetime. A volume driver is the piece of software responsible for actually implementing where and how that volume’s data is physically stored. Docker itself doesn’t need to know the specific details of every possible storage system in the world — instead, it delegates that responsibility to a volume driver, which handles the real work of creating, managing, and providing access to the underlying storage.

This separation between “how you use a volume” and “where that volume’s data physically lives” is precisely what makes volume drivers so useful — it lets the same basic approach to persistent storage work correctly whether your data ends up on a simple local disk or in a large, specialized storage system entirely external to the machine running the container.

A single, one-size-fits-all approach to storage quickly runs into real limitations.

Docker’s default approach to volumes — storing data directly on the local disk of whichever machine is running the container — works perfectly well for a huge number of everyday situations, particularly local development and simple single-machine applications. But real, growing systems eventually run into situations this simple approach genuinely can’t handle well on its own.

Volume drivers exist precisely to address situations like these, letting Docker extend its simple, consistent volume concept to a wide range of genuinely different underlying storage systems, chosen based on what a particular application actually needs.

Every Docker installation comes with one volume driver built in, ready to use immediately.

Unless told otherwise, Docker automatically uses its built-in local driver whenever a new volume is created. This driver stores volume data directly within Docker’s own managed area of the local machine’s disk, requiring no additional setup, external systems, or extra configuration whatsoever. It’s the option almost every beginner uses without ever explicitly choosing it, simply because it’s the sensible, functional default.

Understanding that the local driver is simply one option among several — rather than the only way volumes can work — is the key mental shift needed to properly understand everything else in this guide. Every other driver discussed from here on exists to offer a genuine alternative to this local default, for situations where it isn’t the right fit.

A closer look at how Docker’s plugin system allows storage to be extended without changing Docker itself.

Docker is built around a plugin architecture for several of its capabilities, and storage is one of them. Rather than needing to understand every possible storage system directly, Docker instead defines a standard, consistent way of asking a volume driver to perform a small set of well-defined actions — creating a volume, removing one, providing a container access to one, and so on. Any driver that correctly implements this standard interaction can be used by Docker, regardless of what actual storage technology sits behind it.

flowchart LR
    A["Docker Engine"] -->|"standard driver requests"| B["Volume Driver"]
    B --> C["Local Disk"]
    B --> D["Network File Storage"]
    B --> E["Cloud Storage Service"]
    style A fill:#fafafa,stroke:#171717
    style B fill:#fef2f2,stroke:#dc2626
        

This architecture is precisely what allows entirely new kinds of storage support to be added to Docker over time — by third parties, storage vendors, or cloud providers — without requiring any change to Docker’s own core engine. A new volume driver is simply a new implementation of that same standard interaction, connected to a new kind of underlying storage.

Beyond the built-in local driver, a wide ecosystem of specialized storage options exists.

Because of the plugin architecture described in Chapter 4, a substantial ecosystem of additional volume drivers has developed over time, each connecting Docker’s volumes to a different kind of underlying storage system. These plugin drivers must typically be installed separately before they can be used, but once installed, they’re used through exactly the same basic volume concept as the built-in local driver.

Choosing among these options depends entirely on what a specific application actually needs, and often on what storage infrastructure an organization already operates elsewhere — there’s rarely a single universally “best” choice, only a best fit for a particular set of requirements.

Selecting a driver is a deliberate choice made at the moment a volume is created.

When a new volume is created, it can be explicitly told which installed driver it should use. If no particular driver is specified, Docker simply falls back to the built-in local driver described in Chapter 3. Once a volume has been created with a particular driver, that association is fixed for that volume’s lifetime — a volume doesn’t switch drivers on its own, and changing which driver manages a given set of data typically means creating a new volume with the desired driver and migrating the data across deliberately.

Many drivers accept additional settings beyond simply which one to use.

Beyond just selecting a driver, most volume drivers accept their own additional, driver-specific options at the moment a volume is created — settings that control details particular to that storage system, such as which remote server to connect to, what size limits should apply, or how the underlying storage should be configured. These options are passed through to the driver itself, and Docker doesn’t need to understand their specific meaning; it simply forwards them along faithfully.

This design keeps Docker’s core simple and stable, while still allowing each driver the flexibility to expose exactly the settings relevant to its own particular kind of underlying storage.

Understanding where volume drivers fit relative to the other main way of giving a container access to real storage.

A bind mount, covered in detail elsewhere, connects a container directly to a specific, pre-existing folder on the host machine, giving you full manual control over exactly where the data lives, but tying that container to that specific host path. A volume, by contrast, is managed by Docker itself, through whichever driver is responsible for it — you don’t need to know or manage the exact underlying location yourself.

Volume drivers are precisely what gives volumes their advantage in portability and flexibility over bind mounts, once storage needs grow beyond a single, manually managed local folder.

Perhaps the single most important practical reason volume drivers matter in clustered environments.

As raised in Chapter 2, a genuine challenge appears once containers can be placed across multiple machines in a cluster: what happens to a container’s persistent data if it’s recreated on a completely different machine than before? With the local driver alone, the answer is simple but unhelpful — the data, tied to the original machine’s disk, is left behind, inaccessible from the container’s new location.

flowchart TD
    A["Container needs to restart"] --> B{"Which driver is the volume using?"}
    B -->|"Local Driver"| C["Data only available if container returns to the same machine"]
    B -->|"Network/Cloud Driver"| D["Data available from any machine in the cluster"]
    style C fill:#fafafa,stroke:#171717
    style D fill:#fef2f2,stroke:#dc2626
        

A volume driver connected to shared, network-accessible storage instead solves this directly: because the actual data lives outside any single machine’s own disk, a container recreated anywhere in the cluster can reconnect to the exact same volume and find its data waiting, regardless of which specific machine it ends up placed on. This is precisely why choosing an appropriate volume driver becomes a genuinely important architectural decision in any clustered, multi-machine setup.

Extending storage beyond a single trusted machine introduces new considerations worth taking seriously.

Once a volume driver connects to storage outside the local machine — across a network, or via a cloud provider’s service — the usual concerns of any network-facing system come into play: how the connection between the machine and the storage system is authenticated, whether traffic between them is encrypted, and what access controls exist on the storage system itself, independent of whatever access controls Docker applies at the container level.

Reviewing a volume driver’s own documentation for its specific security recommendations is genuinely important, since the right practices differ meaningfully depending on exactly what kind of storage system a particular driver connects to.

Not all storage options offer identical speed, and this trade-off deserves attention.

The local driver, reading and writing directly to a machine’s own disk with no network involved at all, is generally the fastest available option, simply because there’s no additional communication step between the container and its storage. Network-based and cloud-based drivers introduce at least some additional latency, since every read or write now potentially involves communication across a network to reach the actual storage system.

This isn’t a reason to avoid non-local drivers — for many applications, the durability and portability benefits described in Chapters 2 and 9 are well worth the modest performance trade-off. It simply means the choice of driver should be made deliberately, with an honest understanding of what each option actually offers, rather than defaulting to whichever is fastest without considering whether it actually meets the application’s real requirements.

A driver connecting to external storage introduces a dependency worth actively watching.

With the local driver, storage availability is essentially tied to the local machine’s own disk health, which is relatively straightforward to reason about. With a network or cloud-based driver, storage availability now also depends on the health and reachability of an entirely separate external system, which can fail or become temporarily unreachable independently of anything happening on the machine running the container itself.

A short checklist for choosing and using volume drivers thoughtfully.

Different volume driver choices show up across a wide range of real, production systems.

If none is specified, Docker automatically uses the built-in local driver, as explained in Chapter 6 — you only need to specify one explicitly if you want a different option.

Not directly — as noted in Chapter 6, a volume’s driver is fixed once created, so switching means creating a new volume with the desired driver and deliberately migrating the data across.

Mainly when your storage needs to follow a container across multiple machines, or requires specific durability guarantees the local disk can’t provide, as covered in Chapters 2 and 9.

Often somewhat, since network and cloud-based drivers introduce a network hop, as explained in Chapter 11 — though this trade-off is usually well worth it for the durability and portability they provide.

As explained in Chapter 8, a bind mount ties a container to a specific, manually chosen host folder, while a volume driver lets Docker manage the storage, potentially connecting it to systems well beyond the local machine.

The container may be unable to properly read or write its persistent data, even while appearing to run normally otherwise — which is exactly why dedicated monitoring, discussed in Chapter 12, matters.

A volume driver is the piece of software actually responsible for where and how a Docker volume’s data is physically stored, letting the same simple, consistent volume concept extend far beyond a single machine’s local disk. The built-in local driver serves most everyday, single-machine needs perfectly well, while an ecosystem of network, cloud, and distributed storage drivers exists specifically for situations where data needs to follow a container across machines, meet particular durability requirements, or integrate with existing storage infrastructure. Choosing the right driver — and taking its security and performance characteristics seriously — is one of the more consequential architectural decisions in any application that genuinely needs its persistent data to survive and remain reachable across a growing, multi-machine system.