Overview

BuildKit separates the buildkitd daemon from the buildctl client, with builds represented in LLB, a vendor-neutral format for process dependency graphs. That architecture supports concurrent execution and reuse of cached work, giving teams room to build beyond a single Dockerfile workflow. Docker Engine 23.0 and later use Buildx and BuildKit by default for docker build, so it is also part of many Docker users’ existing stack.

The project is licensed under Apache-2.0 and identifies Moby, Docker, Tekton Pipelines, Gitpod, Dagger, and others as users. Those integrations make BuildKit relevant across developer tooling and CI setups, though it remains a build toolkit rather than a hosted service with a managed workflow.

Key features

Extensible, cache-aware builds

Frontends translate build definitions into LLB; Dockerfiles and other LLB languages are supported. Concurrent dependency resolution, instruction caching, and cache import and export help avoid repeating work, particularly when teams can share cache across environments. Exporters include inline, registry, local directory, and GitHub Actions cache. The project marks GitHub Actions, S3, and Azure Blob cache options experimental, making them less suitable as a critical dependency when a settled cache path is required.

Execution and outputs

Build results can be exported as images, local directories, tarballs, Docker tarballs, or OCI tarballs. That range is useful when a pipeline needs to deliver more than a container image. Automatic garbage collection helps manage build state, while nested jobs, distributable workers, and pluggable architecture provide flexibility for more involved setups.

BuildKit supports execution without root privileges, and its daemon can use OCI (runc) or containerd worker backends. The daemon exposes a gRPC API at /run/buildkit/buildkitd.sock by default and can also use TCP sockets, which suits teams integrating build execution into their own tooling.

Security boundaries

With the default daemon configuration, the API cannot reach the host filesystem outside the BuildKit state directory; application and frontend containers also cannot access the host system, run privileged system calls, or directly access external devices. That is a useful boundary for builds involving untrusted sources, but it does not remove the need to configure and operate the daemon responsibly. Security issues are directed to security@docker.com; the project does not offer a paid security bounty program.

Pricing

BuildKit (Apache License 2.0): 0.00 USD per free (perpetual · worldwide · non-exclusive · no-charge · royalty-free). The free toolkit includes the build features and supported outputs described above, with no paid tier or quota to weigh against a lower-cost plan. Its tradeoff is operational: teams run the daemon and client within their own environment rather than buying a managed service.

Platforms

BuildKit supports Linux, Windows, and macOS, and its latest binaries are available for all three. The macOS caveat matters: the unofficial Homebrew formula does not include buildkitd. The project gives Lima in a Linux VM as one way to run the daemon, so Mac users relying on Homebrew alone will need another setup. BuildKit also supports rootless mode and Windows containers.

Who it's for

BuildKit fits teams that need repeatable container builds, control over build definitions, cache reuse, or integration through a daemon API. It is also a natural fit for Docker users who want to understand or extend the build machinery already used by Docker Engine. It is a weaker choice for teams seeking a hosted, turnkey pipeline or for macOS users unwilling to run the daemon through an alternate environment.

Pros and cons

Pros: Extensible frontends and LLB support more than Dockerfile-only workflows, while concurrent resolution and caching can cut repeated build work.
Pros: Multiple worker backends and output formats let teams fit builds into varied container stacks and artifact handoffs.
Pros: Rootless execution and default host-access boundaries are useful when builds involve untrusted source code.
Cons: BuildKit is a daemon-and-client toolkit, so teams must provide and operate the runtime environment themselves.
Cons: The unofficial macOS Homebrew formula omits the daemon, adding setup work for Mac users.
Cons: Experimental cache options are a risk for teams that need dependable GitHub Actions, S3, or Azure Blob cache behavior.

Alternatives

Earthly is another free option for teams needing API, self-hosted, and web platform coverage alongside Linux, macOS, and Windows. Choose Google Cloud Build when a hosted build service fits better: its default-pool plan bills $0.006 per build-minute after the first 2,500 free build-minutes per billing account each month, with the plan priced at 0.01 USD per month.

werf is a free alternative with Linux, macOS, Windows, API, and self-hosted platform support. Depot is worth considering for teams seeking a paid build platform with a free trial; its Developer plan is 20.00 USD per month for one user, 500 Docker build minutes, 2,000 Depot CI minutes, and 2,000 GitHub Actions minutes.

Cloud Native Buildpacks Pack is a free CLI and Go library for teams who want that tool format instead. Dagger offers a free Individual plan with one user, 1,000,000 monthly events, one month of run history, and community support, making it a candidate when those usage terms suit the workload. Garden has a free tier with limited build minutes, cache hits, and cache retention. Kaniko is a free Linux and self-hosted option for building container images from Dockerfiles.

Browse more options in Container Build Tools and Container Engines.

Verdict

Choose BuildKit if your team wants a free, extensible build engine with reusable caching, multiple outputs, and control over execution in an existing container stack. Its strongest case is flexibility without a license charge; look elsewhere if you need a managed build service or want macOS daemon setup to be straightforward.

	BuildKit	runc
Free plan	Yes	No
Free trial	No	No
Paid from	Free	—
Open source	No	No
Platforms	api, Linux, macOS, self-hosted, Windows	Linux
Free plan	Yes	Yes
Rootless mode	Yes	Yes
Image building	Yes	No
Windows containers	Yes	No
Image format	both	oci
Runtime interface	other	other
Supported host OS	Linux, Windows, macOS	Linux

BuildKit vs runc

BuildKit

runc