Buck2: Meta's hermetic Rust build system and what adopting it costs

Buck2 only sandboxes when Remote Execution is on

Hermeticity is the headline claim in the README, and the footnote attached to that claim is the part worth reading twice. A build rule is required to declare all of its inputs, and a missing declaration, such as a C file that never lists its header, fails the build rather than passing on the machine that happens to have the header lying around. That footnote states Buck2 does not sandbox local-only build steps, while Buck2 with Remote Execution is always hermetic by design. The vast majority of build rules are described as remote compatible, and the README says the project hopes to lift the restriction.

So the guarantee a reader takes from the word hermetic depends entirely on configuration. On a laptop running local steps, the enforcement that would catch an undeclared header is not in effect. If your incident history is a build that worked for one developer and failed for another, that class of bug survives until you turn Remote Execution on. Verify the mode your CI actually runs in before drawing conclusions about dependency tracking.

What the Rust core actually buys, and who it is for

The core executable is language agnostic and written in Rust, with a small API. Even C and C++ support is written as a library on top of that core rather than compiled into it, which means a team that needs an unusual toolchain writes it as a library instead of forking the binary. The repository layout backs this up: crates such as dice for incremental state, allocative, pagable, host_sharing and remote_execution sit beside the app, prelude and build directories.

The audience is large monorepos running several languages with real inter-dependencies. The README describes the common fallback as make tied together with dune, pip and cargo, and asks how you then run test suites, coverage or code queries across all of it. Buck2 answers with one graph, so a Python library can depend on an OCaml library that depends on a Rust crate under a single build tool. That is a good fit for an organization already running code generation across language boundaries. For a single-language repository with a few hundred targets, none of this architecture pays for itself.

Getting a binary: the latest tag, or dotslash

It points at the tags and releases pages for a built binary, and describes the `latest` tag as a moving reference updated on every push to the repository. That matters for what you should expect to see: the `latest` binary is a recent commit rather than a curated build, and it can change under you without a version bump.

The alternative path is dotslash, which the README recommends because it deploys into a repository as a single text file and pulls the correct platform binary as needed. Buck2's own guidance points in the opposite direction: Meta runs the latest committed HEAD at all times, and the README recommends tracking HEAD for filing bug reports and catching regressions. Good for upstream triage, poor for a frozen CI image. There are also buck2.py and buck2.bat files at the repository root.

The prelude Meta runs is the prelude you download

The prelude shipped in this repository is the same code Meta uses internally for its own builds, though Meta retains a large amount of Starlark code on top of that prelude. So what you download is the foundation, not the complete internal configuration.

Layered on the prelude is BXL, the Buck Extension Language, which can introspect the build system and let automation tools inspect and run actions in the graph. The README names language servers and compilation databases as the cases this unblocks. The examples directory ships separate projects for with_prelude, no_prelude, android, bxl_tutorial, bootstrap, hello_world, persistent_worker, toolchains, remote_execution and vscode, which is the fastest way to see which shape fits before you commit a repository to it.

The speed claim is measured against Buck1, not against Bazel

The README states Buck2 is up to 2x faster than Buck1 in practice, and the footnote says that number comes from internal usage at Meta. The same footnote warns that appropriate comparisons with systems like Bazel have yet to be performed, and that Buck1 is the baseline because it existed and had to be replaced. So if you are choosing between Buck2 and Bazel, no evidence here settles it. The README asks you to benchmark Buck2 against your own tools.

The design claims you can inspect instead are more specific. Support for ultra-large repositories comes through filesystem virtualization and watching for filesystem changes, and distributed compilation uses the same Remote Execution API that Bazel supports, with BuildBarn, BuildBuddy, EngFlow and NativeLink listed as working today. The Remote Execution compatibility is the reusable asset here: an existing Bazel remote cache setup is closer to a working Buck2 configuration than the local build path is.

Migration cost lands on the toolchains you lose

The last push to main landed on 2026-11-02, so the code moves often even though the packaging is unfinished.

The README is unusually blunt about outside users. It says external consumers will encounter a lot of rough edges, that several features are missing or in progress, and that some toolchains from Buck1 are missing, with more fiddling than necessary needed to get a setup polished. That is the migration bill: not the Rust binary, which is a download, but the porting work for each toolchain your rules depend on.

The performance budget compounds this. The README says that whether a single build command takes 60 seconds or 0.1 seconds, Buck2 calculates the critical path and gets out of the way with minimal overhead. Paying that setup cost in a repository where a clean build finishes in seconds is a poor trade. Judge the adoption on how much of your Buck1 rule set survives the move, not on the headline speedup, which has no public comparison behind it.

Where Bazel, Pants and the Rust-native tools differ

Buck2 states its position directly: if you know Buck1, Bazel or Pants, Buck2 will feel familiar. The difference is not the build graph model, it is the payload of the executable. Buck2 ships a language agnostic Rust core with a small API where C and C++ support is a library, and its Remote Execution API is the same one Bazel supports, which lets existing infrastructure serve both. Buck2 also describes filesystem virtualization and change watching as a first-class design point for ultra-large repositories.

Cargo is a different category entirely and the README uses it as part of the problem statement rather than a competitor: teams chain cargo to make and dune to pip, then lose a single graph for tests, coverage and code queries. A Rust-only repository with no cross-language edges will find cargo alone simpler. The genuine test is whether your build graph crosses language boundaries often enough that the cost of keeping them in separate tools is already visible in your iteration time.

Editorial conclusion

Adopt Buck2 if you run remote execution against a monorepo large enough that incremental state dominates your build loop, and you have someone who can port missing Buck1 toolchains. Do not adopt it for a small or medium repository, or as a drop-in Bazel replacement, since the README states no comparison against Bazel has been performed. Before anything else, verify whether the Buck1 toolchains your rules depend on have been ported, and run one real remote build, because local builds give you none of the hermeticity the README advertises.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes