May 5, 2026
Disk drama in container land
Docker 29 has changed its default image store for new installs
Docker’s new setup promises smoother app handling, but users are freaking out about storage bloat
TLDR: Docker 29 now uses a new image storage system by default on fresh installs, bringing useful new features but also potentially using more disk space. The comment section instantly fixated on the storage hit, with users calling it insane and some asking if this is finally the moment to switch away from Docker.
Docker just pulled a quiet-but-chaotic move: on new installs, its latest version now stores app images in a different place and in a different way. Docker says most people won’t notice much day-to-day, and the switch unlocks flashy new perks like easier multi-device app builds, better software supply-chain receipts, and even support for WebAssembly apps. But the community absolutely noticed one thing: it can eat more disk space.
That’s where the comments turned into a mini riot. One user basically screamed, “Docker already fills up my dev machines,” then called the new approach “insane” after reading that files may be kept in both compressed and unpacked form. Another commenter warned this could get especially ugly when lots of images share the same base, saying it sounds like a real problem instead of a harmless upgrade. Translation for non-Docker people: your machine may end up keeping extra copies around for speed and compatibility, and some users are not thrilled.
Then came the classic tech-thread energy: “Why not just use podman at this point?” That instantly turned a storage update into an identity crisis. One commenter also pointed out that Docker’s folder is no longer neatly self-contained, which sparked the kind of organizational outrage only developers can turn into theater. And because no online debate stays on topic for long, the thread even swerved into an Apple storage argument. In other words: Docker shipped a backend change, and the internet responded with panic, side-eyes, rival-product evangelism, and a totally unrelated hardware fight. Beautiful chaos.
Key Points
- •Docker Engine 29.0 and later defaults fresh installations to the containerd image store, while upgraded systems remain on legacy drivers until manually changed.
- •The containerd image store uses snapshotters instead of classic graph drivers and is unavailable when user namespace remapping (`userns-remap`) is enabled.
- •The new backend enables local multi-platform image storage, support for image attestations such as provenance and SBOMs, Wasm containers, and advanced snapshotters like stargz, nydus, and dragonfly.
- •containerd uses more disk space because it stores both compressed and uncompressed image layers, with extra overhead when multiple images share the same base layers.
- •Users can enable the containerd image store via `/etc/docker/daemon.json`, but switching backends hides images and containers from the other backend until switched back.