moby/buildkit

What it is

BuildKit is the build engine behind modern Docker builds and many container build systems. It takes a build definition, such as a Dockerfile or another frontend, compiles it into an intermediate format called LLB, and efficiently schedules the work. The architecture separates a Linux daemon (buildkitd) from a client (buildctl), with the client also available for macOS and Windows.

The main reasons to use it are concurrent dependency resolution, reusable instruction caches, and flexible outputs. LLB is vendor-neutral and serialized as Protobuf, so builds do not have to be expressed as Dockerfiles. Results can be written to a registry image, a local directory, a Docker tarball, an OCI tarball, or the containerd image store. Several frontends exist for languages such as HLB, Earthfile, Nix, and YAML-based formats.

Quick start

The daemon needs a Linux host with runc or crun installed, and optionally containerd when using the containerd worker. Start it as root first:

sudo buildkitd

The daemon listens on a Unix socket by default. To run it without root, follow the rootless guide. Then build a Dockerfile from the current directory with the client:

buildctl build \
  --frontend=dockerfile.v0 \
  --local context=. \
  --local dockerfile=.

The build result and cache stay inside BuildKit unless an output is requested. To push an image to a registry:

buildctl build ... --output type=image,name=docker.io/username/image,push=true

To copy the build result to a local path instead, use --output type=local,dest=path/to/output-dir. Prebuilt binaries are available for Linux, macOS, and Windows from the release page; macOS users can also install the unofficial Homebrew formula, but it does not include the daemon and a Linux VM such as Lima is needed for buildkitd.

Outputs and caching

Outputs are selected explicitly. Besides registry images and local directories, BuildKit can produce Docker or OCI tarballs and store images in a containerd image store. A build can emit metadata such as the image digest via --metadata-file.

Cache is also a first-class export/import concern. The inline exporter embeds cache metadata in the pushed image, while the registry exporter stores cache separately and supports a larger max mode. Local, GitHub Actions, S3, and Azure Blob Storage cache exporters are also available, with the latter three marked experimental. Multi-platform builds and cache sharing across a cluster are documented separately.

Constraints and operations

The daemon runs on Linux and Windows, while the client is cross-platform. A containerized daemon normally needs privileged mode; the rootless container image and daemonless mode avoid some of that but have their own requirements. Exposing the gRPC API over TCP without mutual TLS is explicitly discouraged because executor containers can call the API. Garbage collection is configured through the daemon configuration file, and the local cache lives under /var/lib/buildkit by default. The project is Apache-2.0 licensed and accepts contributions through its contributing guide.

HotRepo's take

BuildKit appeared on the Go daily list on 2026-11-04 at position 12 with 2 new stars, a small move for a repository with over 10,000 stars. That is consistent with mature infrastructure: its relevance comes from being adopted by Docker, Buildx, Gitpod, Earthly, and others rather than from rapid star growth. The two Hacker News submissions are narrow implementation notes, including a single comment noting that build volume support existed since 2019, so they offer little signal beyond developer interest in faster pipelines. For teams building container images at scale, the project's value is in cache control and output flexibility rather than in its recent ranking activity.