4.2.12 VOLUME
A focused guide to VOLUME, connecting core concepts with practical Docker and container operations.
VOLUME is the Dockerfile instruction that declares a mount point intended for persistent or externally managed storage, signaling that data written to the specified path should be treated as separate from the container's own disposable, writable layer.
Basic Usage
VOLUME marks a directory inside the image as a location where data is expected to be stored outside the container's own lifecycle.
VOLUME /var/lib/postgresql/data
A container started from this image automatically receives an anonymous volume mounted at this path, even if no volume is explicitly specified at run time.
Why VOLUME Exists
Declaring a path as a volume signals, both to Docker and to anyone reading the Dockerfile, that this location holds data meant to persist beyond a single container's life, distinct from the rest of the image's otherwise disposable filesystem.
docker run -d postgres:16
docker volume ls
Even without an explicitly named volume specified at run time, an anonymous volume is created automatically for the path declared by VOLUME in the image.
Overriding With a Named Volume
A named volume, or a bind mount, can be explicitly specified at run time, taking the place of the automatically created anonymous volume.
docker run -d -v pgdata:/var/lib/postgresql/data postgres:16
This explicitly uses a named volume called pgdata, rather than an anonymous one Docker would otherwise create automatically.
VOLUME and the Build Process
Once a path is declared as a volume, later Dockerfile instructions cannot meaningfully add to it, since changes to a volume's contents made during the build are not preserved the way changes to ordinary layers are.
VOLUME /data
RUN echo "test" > /data/file.txt
This instruction's effect is not reliably preserved in the resulting image, since /data is treated as an external mount point from the moment VOLUME is declared.
Why VOLUME Matters
VOLUME provides a way to declare, directly within the image itself, which locations are meant to hold persistent data, helping anyone running the image understand which directories should be backed by durable storage rather than left to the container's disposable writable layer.