// the find
moby/buildkit
concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
BuildKit is the build engine behind `docker build` since Docker Engine 23.0 — it replaced the legacy builder and is now the default. It exposes a low-level intermediate representation called LLB (think LLVM IR but for build graphs) that lets you build container images, arbitrary artifacts, or multi-platform binaries with aggressive parallelism and content-addressed caching. If you're writing custom build tooling, CI infrastructure, or anything that needs to produce OCI images programmatically, this is the layer you're actually building on top of.
The LLB DAG model is the real win: steps that don't depend on each other run in parallel automatically, and cache keys are content-addressed so a cache hit on layer N doesn't require re-running N+1 even when you switch branches. Cache export is genuinely flexible — inline, registry, S3, Azure Blob, GHA — and the `max` mode exports all intermediate layers, not just the final image, which makes cold CI cache restores much faster in practice. Rootless mode works without privileged containers via user namespaces, which matters for shared Kubernetes clusters where `--privileged` is blocked. The frontend plugin system (anything can implement the LLB protocol, not just Dockerfiles) means tools like Earthly, Dagger, and Nix integrations can use BuildKit as a substrate rather than reimplementing layer caching themselves.
The `buildkitd` daemon is Linux-only (and Windows experimentally); macOS requires a Linux VM via Lima or similar, which adds operational overhead for local dev workflows. The LLB Go API is the only first-class programmatic interface — there's no stable gRPC client contract at the LLB level, so non-Go languages end up shelling out to `buildctl` or wrapping Docker socket calls instead. Garbage collection configuration is powerful but confusing: the TOML syntax for GC policies is not well-documented and the defaults can silently evict cache that took hours to build if disk fills up. Running `buildkitd` as TCP without mTLS is explicitly called out as dangerous because RUN containers can call back into the daemon — but the docs bury the warning rather than making secure-by-default the obvious setup path.