Trace Machina Built NativeLink to Make Your CI Pipeline Stop Wasting Money

The Macro: CI/CD Is Eating Your Cloud Budget and Nobody Talks About It

I want to talk about a number that most engineering leaders prefer not to think about: how much they spend on builds that accomplish nothing. Every CI pipeline in production is rebuilding artifacts that have not changed. Rerunning tests on code that nobody touched. Compiling the same binaries from the same source files because the build system does not remember that it already did this an hour ago. The waste is staggering, and it scales linearly with the size of your engineering team.

The build infrastructure market is quietly enormous. CircleCI, GitHub Actions, GitLab CI, Jenkins, Buildkite. These tools manage the workflow of building and testing code. What they do not do well is avoid redundant work. Bazel, the build system that came out of Google, introduced the concept of hermetic builds and remote caching, which theoretically solves the redundancy problem. But running Bazel at scale requires infrastructure that most companies do not have. The remote execution backend is the hard part, and Google kept theirs proprietary for years.

This created a gap. Companies that want Bazel-style build caching and remote execution need a backend to power it. BuildBuddy has been the most visible player in this space, offering a managed Bazel backend with caching and remote execution. EngFlow is another option, founded by former Google engineers. Both are commercial products with commercial pricing. For large engineering organizations, the cost is justified. For everyone else, it is another line item on the cloud bill.

The open-source alternative has been fragmented. Buildbarn existed but was hard to operate. Bazel’s built-in remote execution protocol was documented but the reference implementations were rough. The gap between “this is theoretically possible” and “this works in production at scale” was large enough to drive an entire category of commercial infrastructure.

The Micro: A Billion Requests a Month in Rust

Trace Machina is the company behind NativeLink, an open-source remote execution and caching platform for software builds. The product is written in Rust, handles over one billion requests per month in production, and counts Samsung among its users. That is not a toy. That is infrastructure at genuine scale.

NativeLink supports multiple build systems including Bazel, Buck2, and Reclient. That flexibility matters because the build system landscape is fragmenting. Bazel is the most popular option for large-scale builds, but Buck2 (from Meta) is gaining traction, and Reclient (from the Chromium project) serves a specific but important niche. A remote execution backend that works across all three has a broader addressable market than one locked to Bazel alone.

The Rust foundation is a deliberate technical choice. Build infrastructure is latency-sensitive and memory-intensive. You are caching and serving potentially millions of build artifacts, each of which needs to be addressable by content hash. Rust gives you the performance characteristics of C++ without the memory safety footprint. That translates directly to lower operational costs and fewer production incidents, which matters when you are handling a billion requests a month.

The project is backed by Wellington Partners and Sapphire Ventures, which gives Trace Machina the runway to invest in the open-source community while building a commercial cloud offering. NativeLink Cloud is available at app.nativelink.com for teams that want the benefits without running the infrastructure themselves. The open-source project has 54 contributors on GitHub, which indicates a healthy community but not yet a massive ecosystem.

The competitive position against BuildBuddy and EngFlow comes down to the open-source advantage. BuildBuddy has an open-source tier but the most valuable features are behind their commercial license. EngFlow is fully proprietary. NativeLink being genuinely open-source means that engineering teams can start with the self-hosted version, evaluate it in production, and convert to the cloud offering when the operational burden of running it themselves exceeds the cost of paying for it. That is a proven go-to-market motion in developer infrastructure.

The Verdict

I think Trace Machina is building in a space where the technical fundamentals are strong and the market dynamics are favorable. Build infrastructure is one of those categories where engineers have strong opinions and are willing to switch tools when something materially better comes along. A billion requests per month in production, with Samsung as a customer, is credible evidence that NativeLink works at scale.

The 30-day question is community growth. How many new contributors and users are joining per month? Open-source developer tools live and die on community momentum. At 60 days, I want to see NativeLink Cloud adoption. Self-hosted is great for credibility, but the commercial business needs managed customers. At 90 days, the question is whether NativeLink can expand beyond Bazel-heavy shops. Buck2 adoption is growing, and being the backend that works across build systems is a meaningful competitive advantage over BuildBuddy’s Bazel-centric approach. The technical foundation is solid. The scale is real. The market is growing. Trace Machina just needs to convert open-source momentum into commercial revenue, which is the oldest challenge in developer tools and the one that separates billion-dollar companies from popular GitHub repos.