Skip to main content
In this lesson we explain how Docker stores data on the host, how image and container files are organized, and how Docker implements writable layers and persistent storage. You’ll learn where Docker keeps runtime files, how layered images and copy-on-write work, and the recommended ways to persist data across container lifecycles.

​
Where Docker stores data

By default Docker keeps its on-disk runtime data under /var/lib/docker. Inside that directory you commonly find subdirectories that map to different parts of Docker’s storage model: Volumes are Docker’s mechanism for persisting data outside a container’s writable layer. While /var/lib/docker is the default location for Docker’s on-disk data, volumes and bind mounts can store data elsewhere on the host.

​
Layered image architecture

Docker images are built as a stack of immutable layers. Each Dockerfile instruction that modifies the filesystem (like RUN, COPY, ADD) produces a new read-only layer containing only the changes from that instruction. Layers are shared between images and containers when possible, which reduces disk usage and speeds up builds. Example Dockerfile (common conventions):
Build the image (context is the current directory):
Because layers are additive and store only filesystem changes, Docker can reuse previously built layers from the build cache, lowering build times and disk usage.

​
Layer reuse example

If a second application uses the same base image and dependencies but different source code or entrypoint, Docker will reuse identical layers (base and dependency layers) and only create new layers for the differences. Second app Dockerfile (differences highlighted):
Build commands:
Because the first three layers match, Docker reuses them from cache and only writes the differing layers, improving build performance and saving storage.

​
Image layers vs. container writable layer

Image layers are read-only. When you run a container from an image, Docker creates a thin writable layer on top of those read-only layers. Any changes made at runtime — logs, temporary files, created or modified files — are stored in that writable layer. Run a container from the image:

​
Copy-on-write (CoW) behavior

If a file is present in a read-only image layer and a process inside the container modifies that file, Docker does not alter the original image layer. Instead, Docker copies the file into the container’s writable layer and applies the modification there; this is the copy-on-write mechanism. The original image remains unchanged; changes are isolated to the container.

​
Writable-layer lifecycle

The writable layer is tied to the container’s lifecycle. When the container is removed, the writable layer and any changes in it are removed as well. To persist data beyond a container’s lifecycle (for databases, uploads, and other stateful workloads), use volumes or bind mounts.

​
Persistent storage: volumes and bind mounts

Docker provides two main mechanisms to persist container data:
  • Volume mounts — Docker-managed volumes stored under /var/lib/docker/volumes.
  • Bind mounts — mount an arbitrary host directory into the container.
Create a Docker volume and mount it into a container:
If a referenced volume name does not exist, Docker will create it automatically:
Bind mount a host directory:

​
Summary of mount types

​
Preferred syntax: —mount

The -v shorthand is older and succinct but less explicit. The newer, recommended --mount syntax uses key=value pairs and makes the mount type and source/target explicit:
Use --mount when you want clarity and to avoid ambiguity in complex mounts.

​
Who manages layers and copy-on-write?

A storage driver implements Docker’s layered model, creates the writable layer for each container, and handles copy-on-write operations. Common storage drivers include: Which driver Docker uses depends on the host OS, kernel, and Docker configuration. Docker usually selects a sensible default, but you can configure the daemon to use a different driver if required. Drivers differ in performance, stability, and features — choose according to your workload and platform.

​
Further reading

Tip: For most modern Linux distributions, overlay2 is a solid default. Run docker info to see which storage driver your Docker daemon is using and evaluate alternatives only if you need features or behavior not provided by that driver.

Watch Video