Tell us about your request
A first-class daemon option to place the image/layer store and build cache on a different backing store from container volumes — not just relocating the entire data-root as a single unit. Ideally each category in docker system df (Images, Containers, Local Volumes, Build Cache) can point at its own path.
Which service(s) is this request for?
Docker Engine (Linux), and by extension Docker Desktop.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I run tiered storage: a large, high-capacity near-online tier for bulk/cold data, and a fast SSD/NVMe tier for hot data. The near-online tier isn't necessarily a single local disk — it might be a big spinning HDD, a bulk SSD array, or a network share such as a 20 TB NAS over 10 GbE. What these have in common is lots of cheap capacity and good sequential throughput, at the cost of higher latency or a network hop. Image layers and build cache fit that tier perfectly: large, cold, mostly read sequentially, and tolerant of the extra latency. Container volumes are the opposite — live application data (databases, working sets) that needs consistent low-latency local I/O, so it belongs on SSD/NVMe. Today everything lives under a single data-root, forcing one bad trade: either burn expensive SSD capacity on a huge cold image cache, or push latency-sensitive volume I/O onto the slow/remote tier. There's no supported way to split them.
Are you currently working around the issue?
Only with fragile hacks — symlinking subdirectories under /var/lib/docker, bind-mounting individual named volumes onto the SSD, or per-volume driver options. None cover the build cache cleanly, and they break across upgrades. Putting the whole data-root on a NAS is a non-starter because it drags the latency-sensitive volumes onto the network too. The recent move to a containerd-backed image store (data landing under /var/lib/containerd) makes hand-rolled symlink setups even more brittle, which is exactly why a supported config knob would help.
Additional context
The capability already exists downstream: the containers/storage library supports an imagestore path distinct from graphroot, and its documented use case is precisely users who want to split the filesystem between "a disk that stores images vs. a disk used by the containers created by the image." So this is largely about surfacing an existing, proven mechanism in Engine/Desktop configuration rather than building something from scratch. A path-based option composes naturally with any backing store the OS can mount — local disk, array, or network share. Related: #239.
Tell us about your request
A first-class daemon option to place the image/layer store and build cache on a different backing store from container volumes — not just relocating the entire data-root as a single unit. Ideally each category in docker system df (Images, Containers, Local Volumes, Build Cache) can point at its own path.
Which service(s) is this request for?
Docker Engine (Linux), and by extension Docker Desktop.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I run tiered storage: a large, high-capacity near-online tier for bulk/cold data, and a fast SSD/NVMe tier for hot data. The near-online tier isn't necessarily a single local disk — it might be a big spinning HDD, a bulk SSD array, or a network share such as a 20 TB NAS over 10 GbE. What these have in common is lots of cheap capacity and good sequential throughput, at the cost of higher latency or a network hop. Image layers and build cache fit that tier perfectly: large, cold, mostly read sequentially, and tolerant of the extra latency. Container volumes are the opposite — live application data (databases, working sets) that needs consistent low-latency local I/O, so it belongs on SSD/NVMe. Today everything lives under a single data-root, forcing one bad trade: either burn expensive SSD capacity on a huge cold image cache, or push latency-sensitive volume I/O onto the slow/remote tier. There's no supported way to split them.
Are you currently working around the issue?
Only with fragile hacks — symlinking subdirectories under /var/lib/docker, bind-mounting individual named volumes onto the SSD, or per-volume driver options. None cover the build cache cleanly, and they break across upgrades. Putting the whole data-root on a NAS is a non-starter because it drags the latency-sensitive volumes onto the network too. The recent move to a containerd-backed image store (data landing under /var/lib/containerd) makes hand-rolled symlink setups even more brittle, which is exactly why a supported config knob would help.
Additional context
The capability already exists downstream: the containers/storage library supports an imagestore path distinct from graphroot, and its documented use case is precisely users who want to split the filesystem between "a disk that stores images vs. a disk used by the containers created by the image." So this is largely about surfacing an existing, proven mechanism in Engine/Desktop configuration rather than building something from scratch. A path-based option composes naturally with any backing store the OS can mount — local disk, array, or network share. Related: #239.