Docker containers are meant to be immutable. The code and data they hold never change. Immutability is useful when you want to be sure that the code running in production is the same that passed QA testing; it’s not so useful when you need someplace to write data and persist it across application lifetimes.

Most of the time, you can address the need for data persistence by using an external database. But sometimes an application in a container just needs to use a local file system, or something that looks like a local file system.

Enter Docker volumes, Docker’s native mechanism for dealing with local storage. A Docker volume is a convenient way to allow containerized apps to write and retrieve data through a local file system or file system like interface. But Docker volumes are not a panacea for managing state. They need to be used wisely.

How Docker volumes work

Docker volumes are a way to map a file path inside a container, called a mount point, to a file system path or file-like object outside the container. Anything written to the Docker volume will be stored externally, so will persist across the lifetime of one or more containers. Plus, multiple containers are allowed to access the same volume at the same time, with some caveats.