Docker Desktop 4.12 experiments with containerd image storage

Docker already uses containerd to manage container execution. The experiment in Docker Desktop 4.12 gives it responsibility for image management as well. The September 1 release notes introduce optional containerd image pulling and storage. Docker's technical announcement explains that the change also replaces Docker graph drivers with containerd snapshotters for preparing container root filesystems.

The interesting consequence is a different representation of the artifact behind familiar commands. Docker wants the existing API and workflows to remain usable. Underneath those interfaces, the content store can retain multi-platform images and other OCI-compatible objects. The experiment therefore concerns more than substituting one downloader for another.

I value Docker's layered images because they give an application environment a concrete artifact that can move between machines. A storage model that can represent that artifact's full platform structure is relevant to that preference. It makes the local image store part of the discussion about what the build produces.

The content store preserves separate image objects

Containerd's content-flow documentation in version 1.6.7, released before today's Desktop update, distinguishes image content from filesystem snapshots. Content normally arrives from a registry, although it can also be loaded directly. The store keeps individual components under names based on their hashes.

An image manifest identifies its configuration object and filesystem layers. An image index identifies manifests for different platforms. Resolving an image reference can therefore require selecting a platform manifest from an index before retrieving the configuration and layers it names. The platform combines an operating system with an architecture.

These objects have different purposes. The index describes available platform variants. A manifest describes a particular image's components. Layer data carries filesystem changes. Treating all of them as one undifferentiated image file hides relationships that matter when a tag refers to more than one architecture.

The documentation's example retains an index as well as the selected manifest and its components. That does not imply every platform's layers must always be downloaded. It shows that the representation can preserve the index while the locally available content includes a particular selected platform. An index and the complete contents of every image it names are separate storage questions.

Docker's announcement identifies native multi-platform storage as a reason to adopt this model. The existing Docker commands remain the user-facing operations, while the content store gains the ability to represent objects beyond a single selected platform image. That distinction explains why an image management change can enable workflows that the command syntax alone does not reveal.

References also govern content retention

The content-flow document describes labels that connect a manifest to its configuration and layer objects for garbage collection. Keeping the manifest must also retain the content needed to use it. An index similarly refers to its platform manifests. These relationships give storage management information beyond the presence of individual files with hash-based names.

For an engineer thinking about image cleanup, the implication is that stored objects form a connected representation. Deleting unused content requires understanding references between those objects. The content store's job therefore includes preserving dependencies as well as retrieving bytes from a registry.

A stored layer is not yet a mounted filesystem

The content-flow document explains that stored layer blobs can be compressed tar data. A container needs an actual root filesystem, so the runtime cannot simply treat a compressed archive as the directory tree it will execute against. Preparing that filesystem is the snapshotter's responsibility.

For each image layer, the snapshotter creates an active snapshot based on its parent. A diff applier interprets the layer data and applies it. The snapshotter commits the result, which becomes the parent for the next layer. After the image layers have been prepared, an active snapshot on top provides the container's root filesystem.

This separates immutable distribution content from the filesystem view used for execution. The content store retains the objects retrieved from the registry. The snapshots represent the results of applying their changes in order. That order matters because a later layer builds on the state produced by earlier ones.

The separation also gives a more precise meaning to image preparation. Downloading the required content and preparing the filesystem are distinct operations. A complete description of startup cost needs to account for both. Improving the transfer of blobs alone does not describe every step needed before a container can use them.

My preference for small final images comes from wanting an explicit application artifact with limited contents. The snapshotter design is compatible with that preference, while making clear that even a small artifact still needs a prepared execution view. Image size and filesystem preparation describe related but different parts of the lifecycle.

Snapshotters provide an implementation boundary

Docker's announcement presents snapshotters as a pluggable replacement for graph drivers. That lets the image management integration use containerd's existing extension mechanism for filesystem preparation. It also aligns Docker with components used by other systems that embed containerd.

The announcement names stargz as an example of lazy image pulling and names nydus and dragonfly in connection with alternative distribution approaches. These are examples of what the architecture can accommodate. Their mention does not establish that every such implementation is configured or supported by the Desktop experimental switch.

That distinction is necessary when reading the release as an engineer selecting capabilities. An extension mechanism can make a future integration practical without making that integration the default behavior today. The specific shipped change is the opt-in containerd image management path. Docker presents the broader mechanisms as reasons to pursue it.

The same restraint applies to performance. The announcement explains architectural opportunities, but supplies no universal improvement factor for enabling the experiment. A change in how content and snapshots are managed can have different consequences for different images and operations. The concrete benefit established here is the new representation and integration path.

Existing Docker operations remain the intended interface

Docker lists run, commit, build, push, load and save among the commands supported with containerd underneath when the experiment is enabled. This is deliberately an integration within Docker. Developers do not need to replace their normal workflow with direct calls to containerd to understand what the release is trying to provide.

That matters to tools that depend on the Docker API. A storage change can affect many callers if it forces them to adopt another interface. Docker instead describes API continuity as a requirement and uses the experimental rollout to gather evidence about existing workflows. The user-facing contract and its internal implementation can evolve at different rates.

The Desktop release announcement places the new switch in Experimental Features. It describes it as opt-in. Installing 4.12 therefore does not mean every developer immediately uses the new image store. An account of behavior under this release needs to say whether the experiment is enabled.

The first stage leaves existing images alone

Docker describes a staged integration. The initial Desktop version supports common workflows without touching existing images. Writing migration code and activating the feature more broadly are later steps in the announced plan. The release should not be described as a completed migration of every local image.

Leaving existing content untouched makes the scope of this experiment clearer. It is a way to exercise the new implementation while avoiding an immediate conversion of the user's established store. That limits what can be inferred merely from enabling the feature. The rollout is gathering feedback on a distinct path before taking responsibility for migration.

Docker also says a future Engine release is expected to receive the integration. That is a direction stated on September 1, not a released Engine capability established by this Desktop update. Desktop provides the initial distribution through which users can try the work.

The local artifact model becomes more expressive

The main change is that Docker can delegate both image content and filesystem preparation to containerd. The content store represents the image objects, and snapshotters prepare the root filesystem used by a container. Existing commands connect the developer to that implementation.

I see the multi-platform representation as the most consequential part of the experiment. An image name can refer to related platform-specific artifacts, and a local store needs a way to preserve those relationships. Desktop 4.12 begins exposing that model through Docker's existing workflows, while the staged plan keeps migration of existing images as a separate piece of implementation work.