BuildKit

Overview

BuildKit pairs the buildkitd daemon with the buildctl client. Builds are expressed as LLB dependency graphs, a vendor-neutral intermediate format designed for concurrent execution and cache reuse. This architecture gives teams more flexibility than a single fixed build-definition format, but it also makes BuildKit a toolkit to integrate into a workflow, not a turnkey hosted builder.

Docker Engine 23.0 and later use Buildx and BuildKit by default for docker build, so Docker users may already encounter it through their existing setup. The project identifies users including Moby and Docker, Tekton Pipelines, Gitpod, Dagger and Depot. BuildKit is licensed under Apache-2.0.

Key features

Builds that can reuse work

BuildKit resolves dependencies concurrently and caches instructions. Cache import and export can carry reusable results between environments, which is useful for teams whose builds run repeatedly across machines or CI jobs. Exporters include inline, registry, local-directory and GitHub Actions cache options; GitHub Actions, S3 and Azure Blob cache options are marked experimental, making them a less settled foundation for workflows that depend on them.

Flexible definitions and outputs

Frontends translate build definitions into LLB. Dockerfiles and other LLB languages are supported, and nested build jobs and pluggable architecture broaden the options for structuring a pipeline. Results can be exported as images, local directories, tarballs, Docker tarballs or OCI tarballs. That range suits teams that need different artifacts from the same build system, though selecting and maintaining the workflow remains the user's responsibility.

Execution and security

BuildKit supports rootless execution and OCI (runc) and containerd worker backends. Its default daemon configuration restricts API access to the BuildKit state directory rather than the wider host filesystem; application and frontend containers cannot directly access the host system, use privileged system calls or reach external devices. These boundaries make it suitable for builds involving untrusted sources, while rootless support gives operators another way to limit privilege.

The daemon exposes a gRPC API at /run/buildkit/buildkitd.sock by default and can also use TCP sockets. Automatic garbage collection helps manage build data, but teams still need to operate the daemon and choose their workers and cache setup. Security issues can be reported privately to [email protected]; there is no paid security bounty program.

Pricing

BuildKit is free: its Apache License 2.0 plan costs 0.00 USD per free, with perpetual, worldwide, non-exclusive, no-charge and royalty-free terms. It includes the build toolkit without a paid tier or stated usage cap, making it a practical option for teams willing to run and integrate the software themselves. The trade-off is operational rather than a cheaper plan with fewer features: BuildKit is not presented as a managed build service.

Platforms

BuildKit supports Linux, Windows and macOS, with binaries for all three and self-hosted use. Rootless mode and image building are supported, and it handles both image formats. macOS users should account for the daemon gap in the unofficial Homebrew formula: the README gives running BuildKit in a Linux VM with Lima as an example. That extra layer makes a native-feeling macOS setup less straightforward than the platform label alone suggests.

Who it's for

BuildKit suits developers and platform teams building container images who need reusable caches, multiple output formats or the freedom to use Dockerfiles alongside other frontends. It is also relevant to Docker users, since recent Docker Engine versions use it by default for docker build. Readers seeking a hosted, managed build workflow, or anyone unwilling to operate a daemon, should look elsewhere.

Pros and cons

• Pros: Concurrent dependency resolution and instruction caching can reduce repeated build work, with cache import and export for reuse across environments.
• Pros: Frontends, multiple worker backends and several output formats let teams adapt builds to their existing pipelines.
• Pros: Rootless execution and default host-access restrictions give teams useful controls when building from untrusted sources.
• Cons: Operators must run and configure the daemon; it is a toolkit, not a managed build service.
• Cons: The unofficial macOS Homebrew formula omits the daemon, so Mac users need another way to run it, such as a Linux VM.
• Cons: Some cache options, including GitHub Actions, S3 and Azure Blob, are experimental.

Alternatives

Dagger is worth considering when a free individual plan with a published monthly-event allowance and run-history window better matches the workflow; its Team plan costs 50.00 USD per US.

Garden may suit teams looking for a freemium option with an Enterprise tier that includes secrets management, RBAC and self-hosting; its free tier has limits on build minutes, cache hits and retention.

Tilt is another free, Apache-2.0 option for users who want a tool spanning Linux, macOS and Windows.

AWS CodeBuild is an alternative for teams preferring usage-based billing for compute resources, with charges tied to build duration and selected compute type.

Cloud Native Buildpacks Pack offers a free CLI and Go library for users looking for that buildpacks approach.

Buildah is a free open-source command-line tool for users who prefer that form of container-image builder.

Kaniko is a free option for building container images from Dockerfiles, distributed as container images.

Paketo Buildpacks provides free open-source buildpacks for building container images.

Browse Container Build Tools or Container Engines for more options.

Verdict

Choose BuildKit if your team wants a free, extensible container build system with reusable caching, varied outputs and control over execution. Its strongest case is the combination of flexible build definitions and cache-aware execution; the reason to look elsewhere is the work of operating it, especially on macOS where the Homebrew formula omits the daemon.