Data layout

This page describes what the daemon stores on disk under its data root (--data-root, default /var/lib/docker on Linux, %programdata%\docker on Windows).

Top-level

<data-root>/
├── containers/<id>/        # Per-container metadata + log files
├── image/<driver>/         # Legacy image store (only present on legacy path)
│   ├── distribution/       # Layer download metadata
│   ├── imagedb/            # Image config blobs (legacy store)
│   ├── layerdb/            # Layer metadata (chainID -> diffID)
│   └── repositories.json   # Tag -> image ID map (legacy refstore)
├── overlay2/  btrfs/  zfs/  vfs/  fuse-overlayfs/  windowsfilter/  ...
│                           # Per-graphdriver layer storage (legacy path)
├── containerd/             # When the daemon supervises its own containerd
├── network/                # libnetwork bbolt DB + per-network state
├── plugins/                # Managed (v2) plugin rootfs and metadata
├── volumes/                # Built-in `local` volumes (under <name>/_data)
├── runtimes/               # Per-runtime configuration files (rare)
├── swarm/                  # SwarmKit raft + state when joined to a swarm
├── tmp/                    # Scratch space for builds, exports, downloads
├── trust/                  # Notary client cache (when content trust is enabled)
└── buildkit/               # BuildKit cache and worker state

The exact set varies by daemon version, OS, and which features are enabled.

Per container

<data-root>/containers/<id>/ typically contains:

config.v2.json          # daemon-side struct (daemon/container/container.go)
hostconfig.json         # API HostConfig
hostname, hosts, resolv.conf  # generated networking files
checkpoints/            # CRIU state (when checkpoint is used)
mounts/                 # Bind sources for tmpfs/secrets/configs (swarm)
secrets/                # Decrypted swarm secrets (in-memory tmpfs on Linux)
config-targets/         # Swarm config files projected into the container
<id>-json.log           # Default `json-file` log driver output
<id>-shm/               # Shared memory mount (when /dev/shm is local)

Legacy image store

Under <data-root>/image/<driver>/:

Subdir	Holds
distribution/	Per-registry pull state (metadata/).
imagedb/content/	Image config blobs keyed by sha256.
imagedb/metadata/	Image-level metadata (parent links).
layerdb/sha256/<chainID>/	Layer metadata: cache-id, diff, size, parent, tar-split.json.gz.
repositories.json	The legacy refstore; tag -> image ID.

containerd-backed path

Under the containerd path, image and layer state live in containerd's own data root (typically /var/lib/containerd/), not in <data-root>. The daemon only stores its non-image state (containers, volumes, networks, plugins, swarm) in <data-root>.

libnetwork

<data-root>/network/files/local-kv.db is a bbolt database holding network and endpoint metadata. Per-sandbox state lives in memory and on the host's /var/run/docker/netns/.

SwarmKit

When the daemon is in swarm mode, <data-root>/swarm/ holds:

• raft/ — the Raft log and snapshot store.
• worker/ — per-task state used by the agent.
• TLS material (certificates/, worker/tls/, manager/tls/).
• The swarm encryption key (when locked, decrypted only with the unlock key).

Cleanups

docker system prune calls into daemon/prune.go which dispatches to per-subsystem prune. Dangling layers are reclaimed by the legacy layer store; containerd snapshotters are pruned via containerd directly.