Build-tool benchmarks published by vendors use repositories chosen to show a difference. Yours is the only one that matters, and both a cold and a warm measurement are needed because CI mostly runs cold.
Terminal
# cold: no cache, the CI condition
rm -rf node_modules/.cache dist && time <tool> build
# warm: the local development condition
time <tool> build
# and the one people forget: incremental after a one-line change
echo "// touch" >> src/index.ts && time <tool> build
A common point of confusion is treating Buildx and BuildKit as alternatives. BuildKit is the backend that actually builds images (concurrent stages, cache mounts, better caching); Buildx is the front-end CLI (docker buildx) that exposes BuildKit features and manages builders. Here is how they relate and what to pick in CI.
Engine vs front-end?
BuildKit is the engine: it parses the Dockerfile into a DAG, runs independent stages in parallel, and supports advanced features like cache mounts (RUN --mount=type=cache) and secrets. Buildx is the user-facing CLI and driver layer that lets you access those features, build for multiple architectures, and run builds in a dedicated
When you need Buildx?
For a plain single-arch build, docker build (now backed by BuildKit by default) is enough. Reach for docker buildx when you need multi-platform images, a container/remote builder that persists cache, or explicit cache export/import to a registry. The docker-container driver is what unlocks cross-platform builds and shareable cache.
In CI?
On CI, use docker buildx build --cache-to/--cache-from against a registry so each run reuses layers from previous runs, and use the docker-container driver for multi-arch. This turns cold, slow image builds into fast, cache-hit builds.
Which should I choose?
Do not choose between them: BuildKit is the engine and Buildx is the CLI that drives it. Use docker buildx when you need multi-platform builds or exportable cache; otherwise BuildKit already powers your default docker build.
