BuildXL: Microsoft's build engine for monorepos at half a terabyte

What BuildXL is, and the scale it was built for

BuildXL, the Microsoft Build Accelerator, is a build engine originally developed for large internal teams at Microsoft. The scale figures in the introduction are the reason to read the rest of the project at all. Internally at Microsoft, BuildXL runs 150,000+ builds per day on monorepo codebases up to a half-terabyte in size with a half-million process executions per build. It uses distribution to thousands of data center machines and petabytes of source code, package and build output caching, and thousands of developers use BuildXL on their desktops for faster builds. So this is not a general purpose build tool that happens to be fast. It is an answer to a specific problem, a monorepo so large that the build graph cannot be evaluated on one machine and the same inputs are compiled over and over across the company. The primary language is C#, the licence is MIT, the last push was on 2026-10-19, and the repository has no GitHub releases, so the project is versioned by internal pipeline rather than by published tags.

The frontends, and the one that is internal only

BuildXL accelerates multiple build languages. The list in the README names JavaScript, MSBuild, and Ninja as used by CMake, plus its own internal scripting language, DScript. DScript is described as an experimental TypeScript based format used as an intermediate language by a small number of teams inside Microsoft, and that description is the honest framing of it. It is not a public alternative to writing a build script in the language of your project, it is an internal intermediate representation, and the fact that it is experimental and used by a small number of teams means you should not plan around it. The three real frontends are the ones that matter for an outside adopter, and the documentation directory has an onboarding page per frontend, at `Documentation/Wiki/Frontends/js-onboarding.md`, `Documentation/Wiki/Frontends/MSBuild/Main.md` and `Documentation/Wiki/Frontends/Ninja.md`. A frontend in BuildXL is a graph producer, the part that turns a build description into the dependency graph the engine schedules.

The caching model, which is the actual product

The performance numbers only make sense given the caching design, and the description points at it directly. BuildXL distributes to thousands of data center machines and caches petabytes of source code, package and build output. The point of a distributed build engine is not parallel execution for its own sake, it is that the same compilation should not happen twice, and the same is true across a company where a shared library is a dependency of a thousand targets. The repository root makes the mechanism visible. There is a `BuildCache.cmd` script, and three configuration files, `BuildCacheDefault.json`, `BuildCacheDefaultNetCore.json` and `BuildCacheOverride.json`, which is the shape of a cache that has a default configuration, a variant for the .NET Core case, and a per-machine override. There is also `RunBxlWithPAT.ps1` and `RunCheckInTestsWithPAT.ps1`, which suggests personal access tokens are used to authenticate against the remote cache.

Where the code lives, and the private and public split

The repository is organised around a split that is worth understanding before you read anything else. There are `Public/` and `Private/` directories at the root, alongside `Shared/`, and the public tree includes the branding directory at `Public/Src/Branding/BuildXL.png`. The `Private/` directory is presumably the part of the engine that is not published, which is the usual arrangement for a build engine that has to talk to internal infrastructure, and it means the open source build is not a complete picture of the internal one. Alongside the directories there are a large number of Windows helper scripts at the root, including `CreatePr.cmd`, `dropout.cmd` and `dropout.ps1`, `killbxl.cmd`, `buddy.cmd` and `domino.cmd`, and the entry points `bxl.cmd` and `bxl.sh`. The `.cmd` extension tells you the daily driver is Windows, with the shell script as the cross-platform alternative, and the `RunCheckInTests.cmd` and `SlimBuildForMacTests.cmd` scripts show the project runs its own check-in tests on more than one platform.

The configuration system, and the dsc files

The configuration surface is visible in the root file list and it is large. There is a `config.dsc`, which is the DScript configuration format, and several variants of it, `config.microsoftInternal.dsc`, `config.nuget.aspNetCore.dsc`, `config.nuget.dotnetcore.dsc`, `config.nuget.grpc.dsc` and `config.nuget.vssdk.dsc`, which are NuGet-oriented configuration sets for specific dependencies. There is also a `cg/` directory, a `secrets/` directory, a `Private/` directory and a `Shared/` directory. The presence of a `secrets/` directory and of scripts named with PAT, personal access token, in their filenames shows where the trust boundary sits. BuildXL talks to a remote cache, and that cache is authenticated. The `.dsc` files are the settings for the engine itself, covering the scheduler and the cache, and the number of them is a fair signal of how much configuration the engine expects you to get right before it will build anything.

Platforms, and the fact that Visual Studio is out of scope

Two things are stated plainly and both matter. The first is the platform support. BuildXL supports Windows 10 and later, Ubuntu 22.04 and 24.04, and Azure Linux 3, which is a short list and covers the plausible deployment targets for a distributed build farm. The second is the interface. BuildXL has a command-line interface, there are currently no plans to integrate it into Visual Studio, and the project is open source in the spirit of transparency of the engineering system. The README says you may find the technology useful if you face similar issues of scale, and adds a disclaimer that BuildXL is not intended as a replacement for MSBuild or to indicate any future direction of build languages from Microsoft. The topics list corroborates the shape, with cli, coreclr, filesystem, kernel, macos, netstandard, orchestration, sandbox, unix, xcode and xplat, which is a list that reads like a distributed systems engine rather than a build script library.

The examples, and where a newcomer should start

The `Examples/` folder is the entry point for understanding the engine by reading it, and the directory names are a good map of what BuildXL can drive. There is a `HelloWorld/` and a `Walkthrough/`, and then `MsBuildHelloWorld/`, `NinjaHelloWorld/` and `CMakeNinjaHelloWorld/`, so the same trivial project expressed in each frontend. Beyond that the examples get specific: `DotNetCoreBuild/` for the .NET Core path, `WorkflowSdkHelloWorld/` for the workflow SDK, `BinaryGraphFragments/` for supplying a pre-built graph, `BlobDaemon/` for a blob-processing daemon, and the cloud test directories `CloudTest/` and `CloudTest-1JS/`. The `MsGuardian/` example suggests a service, and `DynamicGraphWorkingNotes.md` at the repository root is a separate document about dynamic graphs, which is the part of a build engine that is hardest to get right and therefore the part worth reading first if you are evaluating it.

Editorial conclusion

Adopt BuildXL if your monorepo build has outgrown a single machine and you have the infrastructure to run a content-addressed cache and a distributed scheduler. Skip it if you want Visual Studio integration or a replacement for MSBuild, since the project states there are no plans to integrate it into Visual Studio and that it is not intended as a replacement for MSBuild. Before you commit, check that your platform is supported, meaning Windows 10 and later, Ubuntu 22.04 and 24.04, or Azure Linux 3, and read the developer guide in the Documentation directory, because the configuration model is substantial.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/BuildXL on GitHub
4. README