Where Does Buck2 Put Build Outputs?
Where Buck2 puts build outputs under buck-out, what the isolation directory means, and what to back up instead.
Last updated
Buck2 writes everything into buck-out at the project root, subdivided by isolation directory with v2 as the default. Artifacts, caches, and generated files all live under that tree. The folder is disposable output, not source of truth.
That makes backup policy simple: exclude buck-out, keep the repo plus .buckconfig. Content-based paths deduplicate the bytes underneath while the reported paths stay stable per configuration. Reaching for files inside buck-out directly works but fights the tool's design.
Where Buck2 stores this, by platform
<project-root>/buck-out
All build outputs, caches, and metadata under the v2 isolation directory by default. Safe to delete and excluded from backups via its cache marker. Keep .buckconfig and the prelude instead; they define the build.
<project-root>/buck-out
Same project-root layout as Linux. Custom isolation names sit beside v2 when used. Copy logical outputs out rather than archiving the tree, since internal paths shift between runs.
<project-root>\buck-out
Identical buck-out tree on Windows. Deferred materialization can leave listed files unmaterialized until requested. The isolation flag must come immediately after buck2 on every platform.
Frequently asked questions
how do I clean Buck2 build outputs
Delete the buck-out folder at the project root. It carries a cache marker so backup tools already skip it. Configuration lives in .buckconfig and prelude, which are the files worth keeping. Rebuilds regenerate everything deterministically.
how do I use a custom isolation directory
Pass --isolation-dir right after buck2 with a custom name, producing buck-out/<name>/ beside the default v2 tree. Separate names isolate concurrent configurations from each other. Most projects never need more than the default.
why do buck-out paths look like hashes
The engine reports configuration-hash paths while bytes live at content-based paths, with symlinks bridging the two. Copy the logical outputs you need rather than the internal tree. Deferred materialization means some listed files may not exist on disk yet.
Notice an outdated path? Let us know.