HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
moby
buildkit
Go2018–2025
moby / buildkit

buildkit

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

Systems & InfrastructureCreative & MediaDevOps & Cloud
Explore on GitHubRead Hacker News discussions
30Distinct people
36Mentions
0Explicit recommenders
10.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year36 dated mentions

Observed mentions: 2018-04-16 21:09:07 UTC to 2025-12-24 23:32:32 UTC.

02468102018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC514
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC909
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC817
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC404

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
BuildKit BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Key features: Automatic garbage collection Extendable frontend formats Concurrent dependency resolution Efficient instruction caching Build cache import/export Nested build job invocations Distributable workers Multiple output formats Pluggable architecture Execution without root privileges Read the proposal from moby/moby#32925 Introductory blog post https://blog.mobyproject.org/introducing-buildkit-17e056cc5317 Join #buildkit channel on Docker Community Slack NoteIf you are visiting this repo for the usage of BuildKit-only Dockerfile features like RUN --mount=type=(bind|cache|tmpfs|secret|ssh), please refer to the Dockerfile reference. Notedocker build uses Buildx and BuildKit by default since Docker Engine 23.0. You don't need to read this document unless you want to use the full-featured standalone version of BuildKit. Used by Quick start Linux Setup Windows Setup macOS Setup Build from source Exploring LLB Frontends Exploring Dockerfiles Building a Dockerfile with buildctl Building a Dockerfile using external frontend Output Image/Registry Local directory Docker tarball OCI tarball containerd image store Cache Garbage collection Export cache Inline (push image and cache together) Registry (push image and cache separately) Local directory GitHub Actions cache (experimental) S3 cache (experimental) Azure Blob Storage cache (experimental) Consistent hashing Metadata Systemd socket activation Expose BuildKit as a TCP service Load balancing Containerizing BuildKit Podman Nerdctl Kubernetes Daemonless OpenTelemetry support Running BuildKit without root privileges Building multi-platform images Configuring buildctl Color Output Controls Number of log lines (for active steps in tty mode) Contributing Used by BuildKit is used by the following projects: Moby & Docker (DOCKER_BUILDKIT=1 docker build) img OpenFaaS Cloud container build interface Tekton Pipelines (formerly Knative Build Templates) the Sanic build tool vab Rio kim PouchContainer Docker buildx Okteto Cloud Earthly earthfiles Gitpod Dagger envd Depot Namespace Unikraft DevZero dacc Quick start ℹ️ For Kubernetes deployments, see examples/kubernetes. BuildKit is composed of the buildkitd daemon and the buildctl client. While the buildctl client is available for Linux, macOS, and Windows, the buildkitd daemon is only available for Linux and *Windows currently. The latest binaries of BuildKit are available here for Linux, macOS, and Windows. Linux Setup The buildkitd daemon requires the following components to be installed: runc or crun containerd (if you want to use containerd worker) Starting the buildkitd daemon: You need to run buildkitd as the root user on the host. $ sudo buildkitd To run buildkitd as a non-root user, see docs/rootless.md. The buildkitd daemon supports two worker backends: OCI (runc) and containerd. By default, the OCI (runc) worker is used. You can set --oci-worker=false --containerd-worker=true to use the containerd worker. We are open to adding more backends. To start the buildkitd daemon using systemd socket activation, you can install the buildkit systemd unit files. See Systemd socket activation The buildkitd daemon listens gRPC API on /run/buildkit/buildkitd.sock by default, but you can also use TCP sockets. See Expose BuildKit as a TCP service. Windows Setup See instructions and notes at docs/windows.md. macOS Setup Homebrew formula (unofficial) is available for macOS. $ brew install buildkit The Homebrew formula does not contain the daemon (buildkitd). For example, Lima can be used for launching the daemon inside a Linux VM. brew install lima limactl start template://buildkit export BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock" Build from source To build BuildKit from source, see .github/CONTRIBUTING.md. For a buildctl reference, see this document. Exploring LLB BuildKit builds are based on a binary intermediate format called LLB that is used for defining the dependency graph for processes running part of your build. tl;dr: LLB is to Dockerfile what LLVM IR is to C. Marshaled as Protobuf messages Concurrently executable Efficiently cacheable Vendor-neutral (i.e. non-Dockerfile languages can be easily implemented) See solver/pb/ops.proto for the format definition, and see ./examples/README.md for example LLB applications. Frontends BuildKit supports different build languages through frontends that translate build definitions into LLB. The following frontends and tools provide alternatives for defining builds: Project Description Dockerfile Build container images using Dockerfile instructions. Buildpacks Build applications using buildpacks. Mockerfile Example YAML frontend for Ubuntu packages and external dependencies. Gockerfile Build simple Go servers from YAML definitions. bldr (Pkgfile) Build and package software distributions using YAML definitions. HLB Define builds as containerized units of work in a high-level build language. Earthfile (Earthly) Define repeatable builds with Dockerfile-like syntax. No longer actively maintained. Cargo Wharf (Rust) Build Rust container images from Cargo build plans with per-dependency caching. Nix Build container images from Nix derivations and flakes. mopy (Python) Package Python applications into container images using YAML definitions. envd (Starlark) Define container-based development environments for AI/ML. Blubber Build application container images from declarative YAML. Bass Script builds and project infrastructure with a Lisp dialect. kraft.yaml (Unikraft) Build Unikraft unikernel images from Kraftfiles. Massé Define composable container image build graphs in CUE. DALEC Build system packages and container images from declarative specifications. Dexfile Extend Dockerfile syntax with conditions, loops, imports, and functions. Doc
Read the full README on GitHub

What Hacker News says

36 sources
cyberax·Dec 24, 2025
Buildkit is still a separate system, unlike the old builder. So you get that extra step of importing the result back. And since it's a separate system, there are also these strange limitations. For example, I can't just cache pre-built images in an NFS directory and then just push them into the Buildkit context. There's simply no command for it. Buildkit can only pull them from a registry. > Buldkit is far more efficient than the old model. I've yet to see it work faster than podman+buildah. And it's also just plain buggy. Caching for multi-stage and/or parallel builds has been broken since the beginning. The Docker team just ignores it and closes the bugs: https://github.com/moby/buildkit/issues/1981 https://github.com/moby/buildkit/issues/2274 https://github.com/moby/buildkit/issues/2279 I understand why. I tried to debug it, and simply
Read the rest
getting it running under a debugger is an adventure. So far, I found that switching to podman+podman-compose is a better solution. At least my brain is good enough to understand them completely, and contribute fixes if needed.
In A faster path to container images in Bazel
mdaniel·Aug 28, 2025
I'd suspect a great deal of people are secretly benefiting from qemu when they do $(docker build --platform linux/{arm64,amd64}) courtesy of binfmt_misc and a static copy of qemu - https://github.com/moby/buildkit/blob/v0.23.2/docs/multi-pla... - https://github.com/moby/buildkit/blob/v0.23.2/Dockerfile#L16... - https://github.com/tonistiigi/binfmt/blob/buildkit/v9.2.2-54... - https://github.com/tonistiigi/binfmt/blob/buildkit/v9.2.2-54... and https://github.com/tonistiigi/binfmt/blob/buildkit/v9.2.2-54... and let me tell you from first-hand experience, that trying to swap in an updated version of the bundled qemu binary when the static version panics on some mis-emulated instruction is some whooooooo, boy
In QEMU 10.1.0
donno·Mar 20, 2025
Windows is is very similar, the differences are two the layer tarballs. The file system appears in a Files sub-directory as there is a Hives sub-directory for containing the Windows Registry. The other difference is there are two extra PAX headers within the tarball, MSWINDOWS.fileattr which is "32" for a regular file, and "16" for a directory and MSWINDOWS.rawsd which is a special encoding of the security descriptor, which you can think of it as the owner, group and permissions associated with the file (which their standard values can be seen from buildkit here: https://github.com/moby/buildkit/blob/22156ab20bcaea1a1466d2...) I haven't looked into how to handle the Windows Registry aspect as in my exploration I was focused on simply adding a pre-built executable so I didn't need any registry entries created. The other fun gotcha is to en
Read the rest
sure the ENV section contain PATH set to c:\\Windows\\System32;c:\\Windows otherwise you would be unlikely to be able to run any Windows executable.
In Build a Container Image from Scratch
mdaniel·Jul 12, 2024
At the very real risk of talking out of my ass, the new versioned Dockerfile mechanism on top of builtkit should enable you to do that: https://github.com/moby/buildkit/blob/v0.15.0/frontend/docke... In true "when all you have is a hammer" fashion, as very best I can tell that syntax= directive is pointing to a separate docker image whose job it is to read the file and translate it into builtkit api calls, e.g. https://github.com/moby/buildkit/blob/v0.15.0/frontend/docke... But, again for clarity: I've never tried such a stunt, that's just the impression I get from having done mortal kombat with builtkit's other silly parts
In Using S3 as a Container Registry
mdaniel·Feb 6, 2024
and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that they bundle binfmt into the buildkit docker image <https://github.com/moby/buildkit/blob/v0.12.5/Dockerfile#L11...> which itself is compiled against a static copy of qemu <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/D...> with various /proc/sys/fs/binfmt_misc wizardry <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/c...> We ended up switching to using multiarch/qemu-user-static:7.2.0-1 <https://hub.docker.com/layers/multiarch/qemu-user-static/7.2...> which also mutates binfmt_misc in buildx's context in order to exec the static copy of qemu in it but I find their shell script much more legible about what's going on: <https://github.com/multiarch/qemu-user-static/blob/v7.
Read the rest
2.0-1/...> not to mention the fact that it more clearly represents the recent qemu version versus secreting it away inside the moby/buildkit:heheh-good-luck-friend They have an entire GH label for that: https://github.com/docker/buildx/labels/area%2Fqemu and my journey into the buildx sewers started from https://github.com/docker/buildx/issues/1170
In BuildKit in depth: Docker's build engine explained
kylegalbraith·Nov 28, 2023
Hey HN! We're excited to launch our Dockerfile Explorer. It allows you to visualize the lower level build ops (LLB)[0] that a Dockerfile is parsed to that BuildKit is parsed to. We built it to help people leveraging Depot get a better idea of what their Dockerfile is actually equating to at the LLB level. LLB supports 6 core operations: - SourceOp loads source files from a Docker image, git repo, or local build context (e.g. FROM) - ExecOp executes a given command (e.g. RUN) - FileOp creates, copies or removes files and directories (e.g. COPY, ADD, WORKDIR) - MergeOp merges its inputs into a single flat layer (e.g. COPY --link) - DiffOp produces an OCI diff, e.g. "layer", for its inputs (unused in the Dockerfile frontend) - BuildOp evaluates its input as additional LLB operations to add to the graph to allow for dynamic build graphs (also
Read the rest
unused in the Dockerfile frontend) With the Dockerfile Explorer, we run the Dockerfile frontend[1] that BuildKit uses inside of WASM to parse and produce the LLB output locally in your browser. We then embed the Monaco Editor so that you can change your Dockerfile to see how it impacts the LLB output that BuildKit will use to build your Docker image. You can see a quick video and read more details on how it all works here: https://depot.dev/blog/dockerfile-explorer. We'd love any feedback or ideas folks would like around this type of tool! [0] https://github.com/moby/buildkit#exploring-llb [1] https://github.com/moby/buildkit/tree/master/frontend/docker...
In Show HN: Dockerfile Explorer
jacobwg·May 23, 2023
It should yeah, our builders are based on BuildKit rather than Kaniko, which optimizes for building container images in parallel and caching as much as possible. BuildKit also supports some more advanced types of caches, such as cache mounts: https://github.com/moby/buildkit/blob/master/frontend/docker... Both Kaniko and BuildKit can be run in rootless mode - we are not doing this, instead we give every builder access to an isolated VM, so builds are a bit quicker as well by avoiding some of the security tricks that rootless needs to work.
In Show HN: Accelerated Docker builds on your local machine with Depot (YC W23)
4oo4·Feb 16, 2023Submission

Ask HN: Is anyone else struggling with Docker buildx?

I just used docker's buildx for the first time (after being forced to since it's the default) and am already dreading being forced to use it because of the additional complexity and poor documentation. So I had a really simple workflow of using intermediate containers to build something from source, then a prod container that pulls build artifacts from the build container. Yesterday I tried building an image and saw that buildx was the preferred engine since the legacy build is now deprecated, so after reading the docs I got the impression that I could mostly use the same workflow as before. After a few tries of this the buildx plugin would not build anything since would not fully read my dockerfile, or it would not even start the build since it was trying to remove a zfs snapshot from my graph directory that didn't actually exist. Today
Read the rest
I took another stab at it, and find that there's a separate daemon called buildkitd that doesn't seem to be available via the apt packages, so I grab the tarball from GitHub. Then I have to hunt in the repo to find systemd service files. https://github.com/moby/buildkit So I extract the tarball and then find that buildkitd won't start because it seems to be hardcoded to look in /usr/local/bin instead of PATH. I move them there, then my image will actually start building. The build stopped partway through because of an update to Maven, which is not a big deal, but then I find that I can't step into an intermediate container to inspect a broken build, since this isn't exposed anymore. https://stackoverflow.com/a/70715535 I fix the build issue and the build finally succeeds, then I find that the image isn't loaded into my docker daemon, so now I also have to figure that out. It's on me for not keeping up with the transition to buildx, but did anyone else go through this much pain? I'd like to think that there's a path of least resistance or documentation I missed somewhere, but I'm surprised that attempting to do something this simple took this much effort, when the docs for buildx make it seem like it's a drop in replacement. Had I not just invested time in locking down my docker containers with privileges and userns I probably would be looking at using podman instead.
1 points · Open discussion
hddqsb·Jan 27, 2023
I know those questions are rhetorical, but to answer them anyway: > > Nice syntax > Is it though? Before the heredoc syntax was added, the usual approach was to use a backslash at the end of each line, creating a line continuation. This has several issues: The backslash swallows the newline, so one must also insert a semicolon* to mark the end of each command. Forgetting the semicolon leads to weird errors. Also, while Docker supports line continuations interspersed with comments, sh doesn't, so if such a command contains comments it can't be copied into sh. The new heredoc syntax doesn't have any of these issues. I think it is infinitely better :) (There is also JSON-style syntax, but it requires all backslashes to be doubled, and is less popular.) *In practice "&&" is normally used rather than ";" in order to stop the build if any comma
Read the rest
nd fails (otherwise sh only propagates the exit status of the last command). This actually leads to a small footgun with the heredoc syntax: it allows the programmer to use just a newline, which is equivalent to a semicolon and means the exit status will be ignored for all but the last command. The programmer must remember to insert "&&" after each command, or use `set -e` at the start of the RUN command, or use `SHELL ["/bin/sh", "-e", "-c"]` at the top of the Dockerfile. But this footgun is due to sh's error handling quirks, not the heredoc syntax itself. > Are the line breaks semantic, or is it all a multiline string? The line breaks are preserved ("what you see is what you get"). > Is EOF a special end-of-file token You can choose which token to use (EOF is a common convention, but any token can be used). The text right after the "<<" indicates which token you've chosen, and the heredoc is terminated by the first line that contains just that token. This allows you to easily create a heredoc containing other heredocs. Can you think of any other quoting syntax that allows that? (Lisp's quote form comes to mind.) > Where is it documented? The introduction blog post has already been linked. The reference documentation (https://docs.docker.com/engine/reference/builder/, https://github.com/moby/buildkit/blob/master/frontend/docker...) explains the syntax using examples. It doesn't have a formal specification; unfortunately this is a wider problem with the Dockerfile syntax (see https://supercontainers.github.io/containers-wg/ideas/docker...). Instead, the reference links to the sh syntax specification (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...), on which the Dockerfile heredoc syntax is based.
In Rails on Docker
orf·Jan 26, 2023
How would you do this in a generic, reusable way company-wide for any Dockerfile? Given that you don't know the targets beforehand, the names, or even the number of stages. It is of course possible to do for a single project with a bit of effort: build each stage with a remote OCI cache source, push the cash there after. But... that sucks. What you want is the `max` cache type in buildkit[1]. Except... not much supports that yet. The native S3 cache would also be good once it stabalizes. 1. https://github.com/moby/buildkit#export-cache
In Rails on Docker
jbott·Jan 26, 2023
Unfortunately this syntax is not generally supported yet - it's only supported with the buildkit backend and only landed in the 1.3 "labs" release. It was moved to stable in early 2022 (see https://github.com/moby/buildkit/issues/2574), so that seems to be better, but I think may still require a syntax directive to enable. Many other dockerfile build tools still don't support it, e.g. buildah (see https://github.com/containers/buildah/issues/3474) Useful now if you have control over the environment your images are being built in, but I'm excited to the future where it's commonplace!
In Rails on Docker

Showing the 15 most recent of 36 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.