Skip to main content
In this article we explain how Docker stores images, containers, and persistent data on the host. You’ll learn where Docker writes files on Linux, how its layered filesystem and copy-on-write model work, and when to use volumes or bind mounts to persist data. First, on Linux hosts Docker keeps runtime and image data under /var/lib/docker. The exact subfolders depend on the storage driver in use. Typical folders you’ll encounter include aufs, overlay2, containers, image, and volumes.
A diagram titled "File System" showing /var/lib/docker as the root folder with subfolders aufs, containers, image, and volumes, each represented by blue folder icons connected along a dashed vertical line.
The table below summarizes the most important directories under /var/lib/docker and what they contain. Note: when using the default local volume driver, a named volume data_volume maps to a host directory such as /var/lib/docker/volumes/data_volume/_data.

​
Docker image layers (recap)

Docker images are constructed from immutable, read-only layers. Each instruction in a Dockerfile typically produces a new image layer that stores only the differences introduced by that instruction. Common examples of layers include:
  • Base OS layer (e.g., Ubuntu).
  • OS package installation layer.
  • Language or dependency layers (e.g., Python packages).
  • Application source code layer.
  • Entrypoint and configuration layers.
Because layers store only incremental changes, identical lower layers can be reused across images. This improves build speed and reduces disk usage. Example Dockerfiles for two similar apps that share many layers:
Build commands:
When the lower layers match, Docker reuses cached layers and only creates new layers for the differing instructions. This saves time and disk space.

​
Image layers are immutable; containers add a writable layer

All image layers are read-only. When you run a container (for example docker run mmumshad/my-custom-app), Docker creates a thin writable layer on top of the image layers. The container stores runtime changes—logs, temporary files, files created or modified by processes—inside that writable layer.
  • The writable layer is ephemeral: when you remove the container, that layer (and its changes) are removed.
  • The underlying image remains unchanged and reusable by other containers.
If a container modifies a file that originally came from a read-only image layer, Docker uses copy-on-write: it first copies the file into the container’s writable layer, then applies the modification. This preserves the original image artifact.
A diagram illustrating the copy-on-write concept: a Read-Write container layer (showing app.py and temp.txt) on top of Read-Only image layers (showing app.py). The graphic labels the container and image layers and highlights which files are writable versus read-only.
This copy-on-write model allows containers to mutate their filesystem without changing the base image. If you need data to outlive a container (for example, database files), use a volume or a bind mount.
Do not rely on a container’s writable layer for persistent data. Removing the container deletes that writable layer and any data it contains.

​
Volumes and bind mounts

To persist container data beyond a container’s lifecycle, use Docker volumes or bind mounts:
  • Volume: Managed by Docker and stored under /var/lib/docker/volumes for the local driver. They are preferred for portability and decoupling from host paths.
  • Bind mount: Mounts a specific host directory (for example /data/mysql) into the container. Use bind mounts when you need direct access to specific host locations.
Examples:
Preferred explicit syntax: --mount (clearer for complex or production usage):
Prefer --mount for complex or production commands because it is more explicit and less error-prone than the legacy -v syntax.

​
Storage drivers — who implements the layered filesystem?

The storage driver implements the layered filesystem, manages how image layers are stored on disk, and provides the container writable layer with copy-on-write semantics. Common drivers include: Docker chooses a default driver based on kernel features and distribution. Different drivers offer different performance and stability characteristics—test and choose the one that matches your workload and host OS. For in-depth details, see Docker’s storage driver documentation: https://docs.docker.com/storage/storagedriver/
  • Docker stores images, containers, and volumes under /var/lib/docker on Linux.
  • Images are composed of immutable layers; containers add a thin writable layer on top.
  • Copy-on-write preserves image layers while allowing container changes.
  • Use named volumes or bind mounts to persist data beyond a container’s lifetime.
  • The storage driver (overlay2, aufs, devicemapper, etc.) implements these behaviors and influences performance.
Further reading:

Watch Video