Buck2: Meta's Multi-Language Build System, Reviewed for New Adopters

What problem Buck2 solves, and for whom

Buck2 targets repositories where several languages depend on each other and where a single build graph has to cover compilation, tests and code queries. The README describes the common alternative as tying together make with dune, pip and cargo, then discovering that test suites, coverage and code databases have no shared entry point. Buck2's answer is a language-agnostic core executable with a small API, where even C/C++ support is written as a library. Language support lives in Starlark rather than in the binary, so users can implement it themselves.

The audience is narrower than the feature list suggests. The README addresses people already familiar with Buck1, Bazel or Pants, and says those ideas will feel familiar. If your project is one language with one package manager, the abstractions Buck2 adds are cost without return. The project becomes interesting when a Python library depends on an OCaml library that depends on a Rust crate, and you want one consistent command to build and test all of it.

Hermeticity depends on Remote Execution, not on Buck2 alone

The README is explicit that Buck2 becomes hermetic only when using Remote Execution. In that mode a build rule must declare all of its inputs; if a .c file needs a .h file that is not declared, the build fails. That failure is the feature. It removes the class of errors where a build succeeds on one machine because of an undeclared file that happens to be present.

The caveat matters more than the headline. Buck2 does not sandbox local-only build steps, so a purely local build is not hermetic. The README says most build rules are remote compatible and that lifting the restriction is hoped for, but as written, hermeticity is a property of your infrastructure as much as of the tool. If you have no Remote Execution backend, you get the dependency tracking improvements without the enforced correctness.

Buck2 uses the same Remote Execution API as Bazel, and the README names BuildBarn, BuildBuddy, EngFlow and NativeLink as working today. That is a real integration advantage: distributed compilation is not a bespoke protocol.

Installing Buck2 and running the hello_world example

The README points to two download routes: a bi-monthly version from the GitHub tags page, or the latest built binary from the releases page. The latest tag is updated on every push to the repository, so it always refers to a recent commit. The README also mentions dotslash for deploying a bi-monthly release into a repo with a single text file that pulls the correct platform binary.

Once the binary is on your PATH, the repository ships an examples directory. The hello_world example is the smallest entry point, and examples/with_prelude and examples/no_prelude show the two ways a project can relate to the prelude. The examples README documents the individual examples, and the bxl_tutorial directory is where the Buck Extension Language is introduced. The repository layout also shows buck2.py and buck2.bat at the top level, alongside the prelude directory that holds the rule implementations.

For self-introspection, the README describes BXL as the mechanism that lets automation tools inspect and run actions in the build graph, naming LSPs and compilation databases as the features that need it. If you want to see that in practice, the bxl_tutorial example is the place to start rather than the prelude.

No stable release tag, and what that costs you

The README carries a warning section stating that Buck2 does not have a stable release tag, and that pre-release and stable tags will come at later dates. Meta uses the latest committed HEAD at all times. The README recommends tracking HEAD for submitting bug reports and catching regressions, which is honest but also describes a workflow most external teams cannot adopt: you inherit every regression along with every fix.

The practical consequence is that upgrading is not a versioned operation. There is no changelog entry to read for a stable release because there is no stable release. The README also warns that several features are missing or in progress, that some toolchains from Buck1 are missing, and that outside consumers will encounter rough edges. Meta retains large amounts of Starlark code that builds on top of the prelude, and that code is not in this repository. If your build depends on a rule Meta wrote internally, you will be writing it yourself.

The bi-monthly tags soften this. They give you a fixed point to pin, and dotslash makes pinning per-repository practical. That is a workaround for the missing stable release, not a substitute for one.

How Buck2 differs from Bazel, Pants and plain Cargo

Bazel is the closest comparison, and the README treats it that way: the Remote Execution API is shared, and the concepts are described as familiar to anyone who knows Bazel. The difference the README emphasizes is the language-agnostic core. In Bazel, the Java implementation carries more of the build semantics; in Buck2, the core executable has a small API and C/C++ support is a library. That is an architectural claim about where complexity lives, and it is the one to test against your own rules.

Pants is named alongside Bazel as a system whose ideas will feel familiar, and the README does not draw a line between them beyond that. Cargo is a different shape of tool entirely: it is a package manager and build tool for one language, and it has no build graph spanning OCaml or Python. If your repository is Rust only, Cargo already does the job, and Buck2's multi-language abstractions are overhead.

The README also notes that appropriate comparisons with Bazel have yet to be performed. The 2x figure it cites is Buck2 against Buck1 from internal usage at Meta, not against any external tool. Treat that number as a migration result, not a benchmark you can transfer.

Filesystem watching and ultra-large repositories

One of the design criteria the README lists is support for ultra-large repositories through filesystem virtualization and watching for changes. The repository layout supports this: there is a .watchmanconfig at the top level, and watchman is the file-watching service the configuration implies. The prelude, the Rust crates and the Starlark implementation all live in the same tree, which is what makes a single build graph over that tree meaningful.

The cost is a dependency on a watching service and on the virtualization layer behaving correctly on your platform. The README does not document what happens when the watcher misses an event, and it does not describe a fallback for filesystems where watching is unreliable. That is a gap worth probing with your own repository before committing, particularly if your developers work on network mounts or in containers where inotify limits are common.

Buck2's own repository is a reasonable stress case to inspect: the Cargo.toml workspace member list is long, and the build of Buck2 itself runs through Buck2.

Licence and the cost of tracking HEAD

The repository ships LICENSE-APACHE and LICENSE-MIT, and the README badge states the licence as MIT OR Apache-2.0. That dual arrangement is the same permissive pair used across much of the Rust ecosystem, and it is permissive for commercial use. The LICENSE files are the authority; the README badge is a summary. Nothing in the repository indicates a copyleft obligation, but the prelude is code you will vendor into your own repository, so read the licence files before you copy it.

The upgrade cost is the more practical matter. Because there is no stable tag, the upgrade path is: pin a bi-monthly tag or a commit, run your build, and expect to read commit history rather than release notes when something breaks. The README's own advice to track HEAD exists because that is what surfaces regressions early, but it puts the burden of bisecting on you. Budget for that as recurring work, not as a one-time migration.

Editorial conclusion

Buck2 fits teams with large, multi-language repositories that already understand Bazel-style build graphs and can track HEAD or bi-monthly tags. It does not fit small single-language projects, or anyone who needs a stable release tag, because the README states there is none. Before adopting, verify that your toolchains exist in the prelude, confirm which of your build steps must run locally, and check whether you have a Remote Execution backend, since hermeticity is tied to it. The prelude directory is the same code Meta builds with internally, so start there when judging rule coverage.

Frequently asked questions

Official sources

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