Skip to main content
Earlier we walked through four recurring problems with the legacy Docker builder:
  • Packages redownloaded from scratch on every build
  • Secrets leaking into image metadata
  • Architecture lock‑in to the builder machine
  • Independent stages executed sequentially instead of concurrently
All four problems share a single root cause: the legacy builder was designed for a simpler era and lacks modern build engine features. Docker rewrote the build engine and released BuildKit. As of Docker 23.0 (January 2023) BuildKit is the default builder — no flags or special enablement required.
A minimal infographic with the word "BuildKit" large in the center and a timeline beneath showing Docker 1.13 (2017 announced), Docker 18.09 (2018 opt‑in), and Docker 23.0 (Jan 2023 default). The image is credited to KodeKloud.
If you’ve run recent builds you were probably already using BuildKit — the compact BuildKit output (for example the ”[+] Building 12.3s” summary) is a giveaway. Example BuildKit output:
A quick CLI note: BuildKit’s frontend functionality is exposed through Docker Buildx. Most modern Docker packages include the Buildx plugin, and plain docker build routes through BuildKit/Buildx under the hood. When you need advanced BuildKit features you’ll use docker buildx build explicitly.
If you want to see whether the Buildx plugin is installed, check your package list. Buildx is typically included with modern Docker packages.
Example check and confirmation that docker build is routed through BuildKit:
What BuildKit gives you BuildKit provides smarter caching and four features that directly address the problems above. The following table summarizes the mapping between the legacy problems and BuildKit capabilities. Below we walk through each feature with clear examples and expected output.
  1. Cache mounts — avoid re-downloading packages on every build BuildKit cache mounts let a RUN step persist cache directories across builds. To use the --mount syntax you must include the modern Dockerfile frontend directive at the top of your Dockerfile:
The # syntax=docker/dockerfile:1 directive enables frontend features such as --mount. On the first build packages are downloaded from the network; subsequent builds restore those downloads from the cache, dramatically reducing build time. First build (slow):
Second build (fast, cache restored):
  1. Secret mounts — use secrets safely during build BuildKit provides ephemeral secret mounts that exist only for the duration of a single RUN step. The secret is never added to any image layer or the image history, removing a major class of leakage risk.
Dockerfile example (note the runtime secret mount in the RUN command):
Build by supplying the secret from the host:
If you inspect the final image or its history you will not find the secret contents — BuildKit ensures secrets never end up in a layer:
This ephemeral secret behavior is a strong security reason to adopt BuildKit for builds that contact private services.
  1. Multi-platform builds — build for multiple CPU architectures in one command BuildKit supports building and pushing multi-architecture images in a single command and publishes a manifest that points to per-architecture image variants. Consumers pulling the image automatically receive the variant matching their platform.
Build and push for AMD64 and ARM64:
When a user on an Apple Silicon Mac pulls the image they get the ARM64 variant; on an Intel laptop they get AMD64. That’s why many images on Docker Hub “just work” across platforms. Example pull outputs will show different digests for different architectures:
  1. Parallel stage execution — independent stages build simultaneously If your Dockerfile contains independent multi-stage builds (for example separate FROM stages for front-end and back-end that don’t depend on each other), the legacy builder would run them sequentially. BuildKit performs DAG analysis up front, determines independent stages, and runs them in parallel — reducing total build time with no Dockerfile changes required.
Example BuildKit output showing DAG analysis and parallel stage execution:
No Dockerfile rewrites required — you get a free speed-up for independent stages. Quick reference Final notes Everything you already know about Docker images still applies: layers remain, docker history still shows metadata, and standard Dockerfile instructions (FROM, RUN, COPY, ENTRYPOINT) behave the same. BuildKit is a faster, smarter build engine beneath the same Dockerfile syntax you already use — adopt its features (cache mounts, secret mounts, multi-platform builds, and parallel stage execution) incrementally to improve speed, security, and portability. Links and references

Watch Video