BoringCache BuildKit

BoringCache provides a managed BuildKit image for shared Docker layer cache, persistent cache mounts, and supported tool caches. Use it with the BoringCache CLI or GitHub Action. See the Docker setup guide for configuration and requirements.

Report security issues privately through GitHub private vulnerability reporting.

Image

ghcr.io/boringcache/buildkit:v0.34.0-bc

Tags follow upstream BuildKit versions with a BoringCache patch suffix:

• v0.34.0-bc.4 is upstream BuildKit v0.34.0 plus BoringCache patch release 4. Symlink permissions no longer change cache keys, so a build context checked out on macOS reuses layers built on Linux from the same files. Link targets, file contents and regular-file permissions still change the key. Files transferred from a local build context keep their capabilities and set-ID bits, and a cached result that lost them is not reused. Warm builds send only the context files whose size, modification time, mode, owner, group or link target changed, as in upstream BuildKit. A builder that ran an earlier image sends its context once after the upgrade. It retains the cache-mount status messages in the build log: build progress does not mark a starting mount as done, and a mount is reported as published only after its upload succeeds. Its binaries use golang.org/x/net 0.62.0 and a golang.org/x/crypto revision without the deprecated openpgp packages. It includes license notices and native library source identities, and records load timing for cached build steps. It retains Go 1.27.3 and the CA bundle update that rejects the compromised eMudhra certificate paths. It prevents canceled uploads of image metadata after cache export, fixes concurrent cache-key snapshots and updates runtime security dependencies. It retains the managed type=boringcache layer-cache path, concurrent Bake upload coalescing, and opt-in cache-mount and tool-cache support. It also retains the tar extraction containment and dependency security fixes, and fixes a race between solver request cancellation and finalization. Cache-mount archives use stable, readable mount names across workers; archives under previous mount names are not selected by the new names. One daemon-wide limit admits one to four cache-mount archive worker processes from the BuildKit CPU budget and reports active, queued, peak, and wait metrics. Cache mounts can be addressed by their own namespace instead of the layer tag, and a namespaced mount is published merge-safely against the snapshot the publisher merged.
• v0.34.0-bc is the managed stable channel for the latest signed BoringCache patch release on that upstream base.
• latest moves only when BoringCache promotes a new managed BuildKit image.

This image is the BoringCache managed builder image used by the BoringCache CLI and boringcache/one.

Releases

Release tags correspond to managed BuildKit images for Linux amd64 and arm64.

Every exact release image is published with provenance/SBOM attestations, scanned for HIGH/CRITICAL vulnerabilities, and signed by digest with Sigstore/cosign. This public repository signs and verifies the exact image digest before promoting v0.34.0-bc and latest to that digest.

The signed Git release tag also records the image tag and immutable digest. The signing and verification workflows compare that signed metadata with GHCR before trusting the image.

Inspect the image:

docker buildx imagetools inspect ghcr.io/boringcache/buildkit:v0.34.0-bc.4

From a checkout of this repository, verify the signature with its release key:

digest="$(
  docker buildx imagetools inspect \
    ghcr.io/boringcache/buildkit:v0.34.0-bc.4 \
    --format '{{json .Manifest.Digest}}' |
    jq -r .
)"

cosign verify \
  --key .github/release-cosign-v1.pub \
  "ghcr.io/boringcache/buildkit@${digest}"

License

The image contains BuildKit, which is licensed under the Apache License 2.0. BoringCache's changes and the buildkitd and buildctl programs built with them are licensed under the Elastic License 2.0. See LICENSE.md.