9.2.3.4 Compose Volume Drivers

Compose volume drivers specifies, within a volume's declaration in a Compose file, which underlying driver should back that volume's storage, defaulting to the standard local driver but configurable to use an alternative driver for more advanced storage scenarios.

Specifying a Driver for a Declared Volume

The driver option, set on a volume's declaration, determines which volume driver actually backs that volume's storage.

volumes:
  app-data:
    driver: local

This explicitly specifies the default local driver, equivalent to the behavior that would occur even without this explicit declaration.

Using an Alternative Driver Through Compose

For storage needs beyond simple local, single-host persistence, an alternative driver (provided through a Docker plugin) can be specified the same way.

volumes:
  shared-data:
    driver: some-nfs-driver
    driver_opts:
      share: nfs.example.com:/exports/data

Passing Driver-Specific Options

The driver_opts field passes configuration specific to whichever driver is in use, since different drivers typically expect different configuration parameters.

volumes:
  cloud-data:
    driver: rexray/ebs
    driver_opts:
      size: "20"
      volumetype: "gp3"

These options are passed directly through to the specified driver, which interprets them according to its own particular configuration conventions.

Why Most Compose Volumes Don't Need This Configuration

For typical single-host deployments, the default local driver is entirely sufficient, meaning the large majority of volume declarations in a Compose file have no need to specify a driver at all.

volumes:
  app-data:

Why Compose Volume Drivers Matter

The ability to specify a volume's driver directly within a Compose file extends the same flexibility available outside of Compose — supporting networked or cloud-backed storage when genuinely needed — while keeping that configuration consistently expressed as part of the application's overall declarative definition.