Docker Desktop 3.2 makes BuildKit the default for existing installations

An existing Docker Desktop installation now gets the same default builder as a new one. The March 1 release notes for Desktop 3.2.0 make BuildKit the default for all users. That changes the interpretation of an ordinary build command without requiring developers to adopt a different build file. The same release opens the Dashboard at startup and uses iTerm2 for container terminals when it is installed.

I regard the builder change as the more consequential part of this update. Dockerfiles are useful because they make environment construction explicit, and caching determines how practical that construction is during development. Making another build engine the default changes the implementation behind an interface people already depend on.

The build file becomes a dependency graph

BuildKit is not newly invented for this release. Its existing project documentation describes integration with docker build dating back to Docker 18.06. Desktop 3.2 broadens the default to existing installations. Availability and default selection are separate milestones, particularly for a tool that developers can use without consciously choosing its internal engine.

The project describes a binary intermediate format called LLB, which represents the dependency graph for processes involved in a build. It uses Protocol Buffers messages and supports concurrent execution and caching. A frontend converts a higher-level build description into that graph. Dockerfile is one such frontend, so the graph representation does not require the builder to understand only Dockerfiles.

That separation gives the implementation a way to reason about dependencies independently of the syntax used to describe them. Concurrency follows the graph of required work. It should not be read as a promise that every instruction becomes parallel or that every build gets the same speed improvement. Dependencies in a particular build still constrain which work can proceed together.

The README lists concurrent dependency resolution and efficient instruction caching among the implementation's capabilities. It also describes importing and exporting build caches. These are mechanisms a build system can use to reuse work, with their usefulness determined by which inputs and intermediate results remain applicable to the next build.

A default does not select every syntax extension

BuildKit's Dockerfile frontend documentation makes a further distinction. Its experimental syntax uses a frontend image selected by a syntax directive at the start of the Dockerfile. Selecting BuildKit as the engine does not make every experimental Dockerfile extension an unconditional part of every build description.

One documented extension provides cache mounts for compilers and package managers. The mount identifies a directory available during the build instruction. Its sharing option can allow concurrent writers, create private instances for competing writers, or make one writer wait for another to release the cache. Those choices address the behavior of the tool using the directory, not merely where its files live.

Secret mounts solve a different problem. They make a supplied file available during a build instruction without baking that mounted file into the image. The documentation provides a required option that fails the instruction if the secret is absent. This expresses a dependency directly, instead of allowing the build to proceed without a file the operation needs.

That property has a precise limit. A command that reads a mounted secret can still write its contents elsewhere. Keeping the mount out of the resulting image does not change what the invoked program does with the data. The mechanism controls how the builder supplies a file, while the instruction determines what outputs it creates.

I like this separation between build inputs and delivered files. A small final image should contain the service and its runtime requirements. Compiler caches and credentials used to obtain dependencies belong to the construction process, and the build description needs a way to represent that distinction.

Desktop retains a configuration escape route

The release notes document how to disable the default in Preferences under Docker Engine. This is the relevant JSON setting:

{
  "features": {
    "buildkit": false
  }
}

In an existing daemon configuration, the setting belongs in the corresponding object alongside the other configuration. It should not be interpreted as an instruction to discard unrelated settings. The documented switch makes builder selection explicit when comparing behavior between implementations.

The distinction between standalone BuildKit and Docker's integration also matters when reading examples. The BuildKit README uses buildctl for its standalone client and documents output exporters for that mode. Its default standalone result remains internal until an output is requested. The Dockerfile frontend guide tells Docker users to use docker build instead. Copying standalone commands without that context can create confusion about where an image should appear.

The Dashboard exposes a separate part of the workflow

Desktop's visible changes concern access to running containers. The Dashboard now opens automatically, and the Mac terminal integration prefers iTerm2 when available, otherwise using Terminal.app. These changes affect how developers reach container information and a terminal, while BuildKit concerns construction of the image that will run.

The release therefore changes two distinct moments in local development. At startup, the Dashboard brings container management into view. The default builder changes what performs build work behind an existing command. Understanding that distinction makes the update easier to assess, because an interface improvement and a build execution change have different effects even when they arrive in the same Desktop installer.