BuildKit

BuildKit is a build system for turning source code into repeatable artifacts, aimed at developers and teams who need control over build definitions, execution, and caching. It suits infrastructure-minded users better than people looking for a turnkey desktop app.

Overview

BuildKit separates its daemon, buildkitd, from the buildctl client. Its LLB intermediate format represents process dependency graphs, allowing builds to run concurrently and reuse cached work. The project identifies Moby, Docker, Tekton Pipelines, Gitpod, Dagger, and others as users, and its code is licensed under Apache-2.0.

Docker Engine 23.0 and later use Buildx and BuildKit by default for docker build. That makes BuildKit relevant even to developers who encounter it through Docker rather than adopt it as a separate build system.

Key features

Flexible, cache-aware builds

Frontends translate build definitions into LLB; Dockerfiles and other LLB languages are supported. Concurrent dependency resolution and instruction caching can reduce repeated work, while cache import and export let teams carry reusable results between environments. Exporters include inline, registry, local-directory, and GitHub Actions cache options. GitHub Actions, S3, and Azure Blob cache options are marked experimental, so they are a less settled choice for workflows that depend on them.

Build results can be exported as images, local directories, tarballs, Docker tarballs, or OCI tarballs. Automatic garbage collection helps manage accumulated cache, and nested build jobs, distributable workers, and pluggable architecture give operators room to shape more complex build setups. That flexibility is valuable when a team needs tailored pipelines; it also means BuildKit is a building block, not a complete guided workflow.

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 rest of the host filesystem; application and frontend containers cannot directly access the host system, use privileged system calls, or reach external devices. Those boundaries make it a credible option for builds involving untrusted sources, while operators still need to understand and configure the daemon that controls the build environment.

The daemon exposes a gRPC API, using /run/buildkit/buildkitd.sock by default, and can also use TCP sockets. Support is directed to the #buildkit channel on Docker Community Slack.

Pricing

BuildKit is free under the Apache License 2.0. The perpetual plan costs nothing, with worldwide, non-exclusive, no-charge, royalty-free terms. There is no paid tier described; the trade-off is that users should expect to operate the build tooling themselves rather than buy a bundled commercial service.

Platforms

BuildKit supports Linux, macOS, and Windows, with API and self-hosted deployment options. Binaries are available for all three desktop operating systems. macOS has an important catch: the unofficial Homebrew formula does not include the buildkitd daemon. The project points to running the daemon in a Linux VM with Lima as one route, so Mac users should plan for that extra setup rather than expect a native, all-in-one installation.

Who it's for

BuildKit is best for developers and platform teams who want reusable build caches, multiple output formats, extensible definitions, or rootless execution and are comfortable managing build infrastructure. It is also a natural fit for Docker users whose builds already use Buildx. Those seeking a simple desktop interface or a managed, end-to-end container workflow should look at alternatives instead.

Pros and cons

• Pro: Cache import/export, concurrent resolution, and several output formats support efficient pipelines that need to produce artifacts for different destinations.
• Pro: Extensible frontends and LLB let teams go beyond Dockerfiles without giving up a shared build graph.
• Pro: Rootless execution and default host-access restrictions are useful safeguards when building untrusted inputs.
• Con: The daemon-and-client architecture asks users to operate infrastructure, which is a poor fit for those seeking a turnkey app.
• Con: The unofficial macOS Homebrew formula omits the daemon, adding a Linux VM or another daemon setup to Mac workflows.
• Con: Several cache options are experimental, making them a riskier foundation for workflows that need stable integrations.

Alternatives

Choose Docker Desktop if you want a freemium Docker-oriented option across desktop platforms; its free Personal plan has limits of one user, one Docker Scout-enabled repository, 100 Docker Hub pulls per hour, and one private Docker Hub repository.

Apptainer is a free open-source container platform, with commercial support available through partners. Incus is free Apache 2-licensed software. Moby is another free option in this category. Podman offers free container, pod, and image management, including Podman Desktop. For a container runtime rather than a build system, consider containerd or crun. LXD is an alternative for KVM-based virtual machines and system containers with self-hosted deployment.

Browse Container Build Tools for more build-focused options, or Container Engines for software aimed at running containers.

Verdict

BuildKit is a strong choice for teams that want precise control over repeatable builds, cache reuse, execution security, and artifact outputs without paying for a license. Its flexibility is the main reason to choose it; the need to manage the daemon, particularly on macOS, is the main reason to look elsewhere.