# Install buildkitd with Homebrew Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit (Daemon). Version 0.31.1 via Homebrew; verified 2026-06-24. ## Install ```sh sudo av install brew:buildkitd ``` Additional install commands: ### macOS - Homebrew (100%): ```sh brew install buildkitd ``` Evidence: local Homebrew formula metadata ## Package facts - **Package key:** brew:buildkitd - **Package manager:** Homebrew - **Package manager page:** - **Version:** 0.31.1 - **Source summary:** Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit (Daemon) - **Homepage:** - **Repository:** - **Upstream docs:** - **License:** Apache-2.0 - **Source archive:** - **Last updated:** 2026-06-24T21:00:10Z - **Generated:** 2026-07-08T07:18:31+00:00 ## Executables - buildkitd (cli) - buildkitd (alias) ## Dependencies - runc ## Build dependencies - go ## Install behavior - Post-install hook: not defined - Service: declared - Caveats: To run buildkitd as the current user, see the following steps: OCI worker mode: brew install rootlesskit rootlesskit buildkitd containerd worker mode: brew install nerdctl containerd rootlesskit slirp4netns containerd-rootless-setuptool.sh install CONTAINERD_NAMESPACE=default containerd-rootless-setuptool.sh install-buildkit-containerd To run buildkitd as the root user, use `brew services` with `sudo --preserve-env=HOME`. - Bottle: available on arm64_linux, x86_64_linux ## Freshness - Page generated: 2026-07-08 - Package-manager version: 0.31.1 - Package-manager updated: 2026-06-24 - Local data: ok - Upstream repository: https://github.com/moby/buildkit - Upstream latest detected: v0.31.1 (current) ## Project history and usage `buildkitd` is the daemon side of BuildKit: the long-running service that executes BuildKit build graphs, manages workers and cache, and exposes the API used by `buildctl`, Docker Buildx, and other clients. ### Project history The daemon exists because BuildKit was designed as a reusable backend rather than a monolithic CLI operation. The 2017 Moby proposal described BuildKit as a long-running service optimized for parallel execution, complex projects, and multiple builds at the same time. In the BuildKit repository, `buildkitd` is documented as the daemon paired with the `buildctl` client. It supports OCI and containerd worker backends, rootless operation, systemd socket activation, TCP exposure, Kubernetes/containerized deployments, and daemon configuration through `buildkitd.toml`. ### Adoption history `buildkitd` adoption followed BuildKit adoption: once Docker Buildx and then Docker Engine 23.0 made BuildKit the default build engine, the daemon became the infrastructure component behind many local, remote, and CI builder setups. The daemon is especially visible outside Docker Desktop and Docker Engine defaults, where users run BuildKit directly on Linux hosts, in Kubernetes, in containers, or from macOS through a Linux VM such as Lima. ### How it is used Users start `buildkitd` as root or rootless, point clients at its Unix socket or TCP endpoint, and tune behavior with `/etc/buildkit/buildkitd.toml` or `~/.config/buildkit/buildkitd.toml`. It manages worker backends, garbage collection, cache storage, network settings, entitlements, and registry configuration. Package-manager users care about `buildkitd` when they need a real BuildKit service instead of only the `buildctl` client, for example to run local CI builders, expose a remote build farm endpoint, or experiment with non-Docker workers. ### Why package nerds care `buildkitd` is the boring but important half of BuildKit packaging: without the daemon, `buildctl` is just a client. Splitting the Homebrew formula surface between BuildKit tools and the daemon reflects the practical difference between a portable CLI and a Linux-oriented build service. For people who package container tooling, `buildkitd` is a case study in shipping a service-oriented build engine whose useful configuration is mostly runtime paths, sockets, workers, and cache policy rather than project-local config files. ### Timeline - 2017: BuildKit proposal describes a long-running build service. - 2017: Public `moby/buildkit` repository is created. - 2023: Docker Engine 23.0 makes Buildx and BuildKit the default Docker build path. - 2026: `buildkitd.toml` remains the documented daemon configuration surface. ### Related projects - `buildkitd` is part of BuildKit and is used with `buildctl`, Docker Buildx, Moby/Docker, containerd, runc/crun, Lima, Kubernetes, and OCI image tooling. ### Sources - - - - ## Security Notes formula declares a Homebrew service. - **Geiger risk:** orange / medium - formula declares a Homebrew service ## Configuration and credential file locations These source-backed paths show where this package keeps local settings or durable credentials. Automic Vault can use them as review targets for secret scanning, migration, and command approval. ## Configuration files - Unix: /etc/buildkit/buildkitd.toml, ~/.config/buildkit/buildkitd.toml ## Source Database Details - **Source Database:** Homebrew formula API - **Tap:** homebrew/core - **Full Name:** buildkitd - **Version Scheme:** 0 - **Revision:** 0 - **Head Version:** HEAD - **Requirements:** linux - **Bottle Stable Root URL:** - **Deprecated:** no - **Disabled:** no - **Keg Only:** no - **URL Keys:** head, stable ## Related links - [Cloud CLI packages](https://www.automicvault.com/pkg/cloud-clis/) - Belongs to a cloud or infrastructure command family. - [Source-control packages](https://www.automicvault.com/pkg/source-control-tools/) - Belongs to a source-control command family. - [Secret-risk packages](https://www.automicvault.com/pkg/secret-risk-packages/) - Has protected-tool coverage, approval-gate, or non-low Geiger security signals. - [Terminal utility packages](https://www.automicvault.com/pkg/terminal-utilities/) - Matched terminal and command-line workflow metadata. - [runc](https://www.automicvault.com/pkg/brew/runc/) - Runtime dependency declared by Homebrew. - [go](https://www.automicvault.com/pkg/brew/go/) - Build dependency declared by Homebrew. - [buildkit](https://www.automicvault.com/pkg/brew/buildkit/) - Shares the same upstream source repository. - [build2](https://www.automicvault.com/pkg/brew/build2/) - Shares av.db curated category or tags: build-systems, cli, developer-tools. - [docker-buildx](https://www.automicvault.com/pkg/brew/docker-buildx/) - Shares av.db curated category or tags: buildkit, cli, containers, developer-tools. - [docker-engine](https://www.automicvault.com/pkg/brew/docker-engine/) - Shares av.db curated category or tags: cli, containers, daemon, developer-tools. - [meson](https://www.automicvault.com/pkg/brew/meson/) - Shares av.db curated category or tags: build-systems, cli, developer-tools. - [xmake](https://www.automicvault.com/pkg/brew/xmake/) - Shares av.db curated category or tags: build-systems, cli, developer-tools. - [cargo-cache](https://www.automicvault.com/pkg/brew/cargo-cache/) - Shares av.db curated category or tags: cache, cli, developer-tools. - [cdebug](https://www.automicvault.com/pkg/brew/cdebug/) - Shares av.db curated category or tags: cli, containers, developer-tools. - [dockerfilegraph](https://www.automicvault.com/pkg/brew/dockerfilegraph/) - Local package facts share a topical domain. Shared terms: cli, containers, developer, developer-tools, dockerfile. - [octobuild](https://www.automicvault.com/pkg/brew/octobuild/) - Local metadata places this package in an adjacent workflow. Shared terms: build, builder, cache, cli, developer. ## Combined YAML source View the package source record on GitHub. [combined/buildkitd.yml](https://github.com/automic-vault/db/blob/main/combined/buildkitd.yml) ## Sources - Nucleus package database - Geiger risk classifier - package-page enrichment - curated configuration and credential file locations - curated package history - package version freshness - av.db category and tag curation - package relationship graph - cross-ecosystem install command graph