Automic VaultAutomic Vault

brew

Install buildkitd with Homebrew

Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit (Daemon). Version 0.31.1 via Homebrew; verified 2026-06-24.

Install commandSecurity notes

install

Additional install commands

macOS

Homebrewverified · 100%
brew install buildkitd

local Homebrew formula metadata

overview

Package summary

Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit (Daemon)

Commands and aliases

  • buildkitd

history

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.

security posture

Risk level: orange

formula declares a Homebrew service.

Risk classifier

orange risk · medium confidence · infrastructure

Why

  • formula declares a Homebrew service

Signals

  • metadata:service

Install behavior

  • No Homebrew post-install hook is recorded in formula metadata.
  • Formula metadata declares a service or daemon block.
  • Homebrew bottle metadata is available for 2 platform targets.
  • Installs with 1 runtime dependencies.
  • Build metadata lists 1 build dependencies.

Recommended review

Before unattended agent use, check whether the tool reads plaintext credentials, writes remote state, publishes artifacts, or shells out to plugins.

local files

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

Config paths the tool may read or write during local use.

Unix
/etc/buildkit/buildkitd.toml~/.config/buildkit/buildkitd.toml

executables

Installed executables

CommandKindExposureNote
buildkitdcliglobal executable

freshness

Version and freshness

These signals separate page generation age, package-manager activity, and upstream release comparison. Version lag is warned only when an evidence URL and comparable versions are present.

page generated2026-07-08
manager version0.31.1
manager updated2026-06-24
local dataok
upstreamcurrent
latest detectedv0.31.1

https://github.com/moby/buildkit

  • okNo freshness warnings were generated.

install metadata

Package metadata

Package keybrew:buildkitd
Version0.31.1
Package managerHomebrew
Package manager pagehttps://formulae.brew.sh/formula/buildkitd
Homepagehttps://github.com/moby/buildkit
Repositoryhttps://github.com/moby/buildkit
Upstream docshttps://docs.docker.com/build/buildkit/toml-configuration
LicenseApache-2.0
Source archivehttps://github.com/moby/buildkit/archive/refs/tags/v0.31.1.tar.gz
Last updated2026-06-24T21:00:10Z
Pulseupdated
Dependenciesrunc
Build dependenciesgo
Bottleavailable (on arm64_linux, x86_64_linux)
Homebrew post-installnot defined
Servicedeclared
CaveatsTo 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`.

registry facts

Source database details

Source DatabaseHomebrew formula API
Taphomebrew/core
Full Namebuildkitd
Version Scheme0
Revision0
Head VersionHEAD
Requirements
  • linux
Bottle Stable Root URLhttps://ghcr.io/v2/homebrew/core
Deprecatedno
Disabledno
Keg Onlyno
URL Keys
  • head
  • stable

package graph

Links come from deterministic package relationships, av.db category and tag curation, ecosystem matches, and package hub membership.

Related tools

  • runcRuntime dependency declared by Homebrew.
  • goBuild dependency declared by Homebrew.
  • buildkitShares the same upstream source repository.

Same workflow

  • build2Shares av.db curated category or tags: build-systems, cli, developer-tools.
  • docker-buildxShares av.db curated category or tags: buildkit, cli, containers, developer-tools.
  • docker-engineShares av.db curated category or tags: cli, containers, daemon, developer-tools.
  • mesonShares av.db curated category or tags: build-systems, cli, developer-tools.
  • xmakeShares av.db curated category or tags: build-systems, cli, developer-tools.
  • cargo-cacheShares av.db curated category or tags: cache, cli, developer-tools.

source trail

Generated from repository data

This page is generated by av-web from the private package SQLite artifact built by scripts/generate-pkg-sqlite.py.

Used sources

  • Geiger risk classifier
  • Nucleus package database
  • av.db category and tag curation
  • cross-ecosystem install command graph
  • curated configuration and credential file locations
  • curated package history
  • package relationship graph
  • package version freshness
  • package-page enrichment