Nx is an Integrated Build Platform, which combines an advanced build system with innovative continuous integration and AI features.
The core of the platform is the Nx CLI, an MIT-licensed build system used by millions of developers. It provides tremendous value to teams who manage to scale their Nx repos with DIY cache solutions.
This post compares using the full platform against using only the Nx CLI with a DIY cache.
What the Nx Platform Adds
It adds two critical capabilities beyond remote caching:
Fast, Reliable CI That Scales Effortlessly
The platform shifts responsibility for fast, reliable CI from the external CI platform into the build system itself. Instead of treating CI orchestration as a separate concern, it handles scaling out work, leveraging caching, parallelism, and distributing compute to speed up validation. The only thing you need to do in your CI provider is specify which commands you want to run, and Nx will handle the rest.
Self Healing CI: AI Agent Automatically Fixing Broken PRs
The Nx platform includes an AI agent that detects and fixes broken pull requests automatically while the CI is still running. It will rerun flaky tasks, will analyze environmental issues, and, most importantly, it will generate and sometimes even automatically commit fixes for code issues.
Comparing Nx Platform and DIY
To compare the Nx platform with a DIY solution we created a repository with two similar CI setups: one uses the full Nx platform, the other uses only the Nx CLI and implements CI using a well-designed DIY distributed solution: https://github.com/vsavkin/benchmark-repo.
Every DIY cache implementation, including first-party packages provided by Nx, has the CREEP vulnerability. This means that every DIY solution has two usage patterns: Safe and Unsafe. The Nx platform’s remote cache is always safe.
Two usage patterns of DIY cache:
- Safe usage: On average, the DIY cache hit rate is around 30%.
- Unsafe usage: On average, the DIY cache hit rate is around 60%, which is comparable with the Nx platform’s remote cache.
Organizations in regulated industries are required to use the cache safely. Despite this, most organizations run DIY cache in unsafe mode. The benchmarks in this document assume unsafe DIY cache usage, meaning the performance differences would be significantly larger with safe cache implementation.
Benchmarks
CI Time
We measured CI time at approximate p50 and p95 by running several common pull request types in the two repos. The p95 case represents a nearly full rerun (e.g., when a core library changes). The p50 case represents a PR rerun where a lot of targets are cached or a change affects only part of the repo.
Results
P50
- Nx platform - Validation step: 3m 54s. Whole pipeline: 6m 11s
- DIY. - Validation step: 5m 49s. Whole pipeline: 8m 1s
P95
- Nx platform - Validation step: 9m 11s. Whole pipeline: 11m 23.
- DIY - Validation step: 15m 53s. Whole pipeline: 18m
The Nx platform is 30-40% faster. This speed comes from its powerful distribution mechanism that uses all the metadata Nx knows about your workspace. Nx allocates tasks efficiently across machines, shares files effectively, and splits large tasks (like e2e test suites) into smaller units, which improves compute allocation and CI time. Again, the difference will be most substantial if the DIY cache was used in a safe manner.
Note, the result is delivered without an increase in compute.
To demonstrate this in a real-world scenario, here’s an example of a CI run on a large monorepo. Each blue bar represents a batch of tasks running concurrently. It highlights how Nx splits and packs tasks to achieve near-perfect utilization of all available VMs.
Configuration
With the Nx platform, the CI configuration is just 31 lines (see here) compared to 231 lines (see here) with the DIY setup. The DIY configuration is 7.5x longer. It’s also more complex and error prone. And as your repository grows or changes, you won’t need to constantly adjust your CI to keep it fast; Nx handles that automatically.
In real projects, the contrast is even more dramatic. When building the Nx platform and migrating our CI to use it, our CI configuration shrank by 10x. That translates to less maintenance, greater predictability, and easier organization-wide standardization.
The Real Impact is Increased Time-to-Green and Team Velocity
While the Nx platform substantially improves CI time and compute compared to DIY, the bigger difference is how it affects team velocity. We measure this through:
- Number of interruptions per PR - ~ number of failed CI runs
- Time-to-green (TTG) - Time to get a PR to its first green mergeable state
- Time-to-final-green (TTFG) - Time to the final green PR before merge
As researchers at Microsoft showed, developers spend only 11% of their time writing code. The majority of their time is spent on other activities, including attending to their failing PRs. Metrics like TTG and TTFG correlate directly with team velocity.
And the combination of interruptions and TTFG determines developer time saved by the Nx platform.
The Effect of CI Speed on Velocity
CI typically requires multiple runs to reach a green state. Each failed attempt is a costly interruption.
Optimizing CI time through remote cache and distribution provided by the Nx platform does reduce TTG and TTGG. For instance, if CI drops from 30 minutes to 15 minutes and you run it twice on average, you save 30 minutes total.
However, cache and distribution don't reduce the number of failures. They just make failures happen faster. If CI fails due to flaky tasks or code issues, it fails in 15 minutes instead of 30, but you still face the same interruption.
The Effect of Nx Platform’s AI Agent on Velocity
Each interruption is expensive:
- Research shows every interruption costs on average 45 minutes of developer time, often more
- There's a gap between when CI fails and when a developer addresses it, meaning failed CI can increase TTG and TTFG by hours.
- The impact extends beyond individual PRs—blocked merges create second-order effects that further reduce velocity
How Nx Platform Reduces Interruptions
- Automatic deflaking - The platform deflakes flaky tasks, ensuring CI only fails for legitimate reasons. It uses a hybrid approach: a probabilistic model based on historical workspace data plus an agentic step that identifies flaky tasks. This resolves 95%+ of flaky failures.
- Automatic fixes - The platform fixes failed pull requests by proposing and validating code changes. Even in large scale monorepos, about 60%+ of these fixes are accepted. When configured, it automatically applies straightforward fixes.
The platform also identifies CI failures caused by broken environments or bad repo state. This doesn't eliminate the interruption but drastically reduces investigation time. Measuring this impact requires actual development work, so sandbox benchmarks cannot capture it. Instead we will show the impact across different real world workspaces.
Real-World Impact
This is a sample of our enterprise clients. Note, the agent’s ability to generate useful fixes and assessments does not deteriorate as the repository grows. This consistency is largely thanks to Nx, which extracts valuable metadata from any repo to ensure the AI agent receives only the most relevant context.
This is how it affects team velocity:
The impact of remote caching is much stronger in time-to-final-green, since the same PRs are rerun multiple times and more targets end up cached. But even in this case the rest of the platform (especially Nx’s AI agent) has a much larger impact.
Note that these savings are per PR. It’s common to see TTG and TTFG decrease by several hours, resulting in thousands of hours saved per month. Also, in some cases, the number of interruptions (i.e., failed CI runs) is reduced by 40% or more.
When using a DIY setup with an unsafe remote cache, the cache-related gains (blue) are similar, but, as you can see, they typically account for only 20–40% of the total impact. This means the Nx platform realistically provides a 3–5× productivity improvement compared to a DIY solution with a self-hosted cache.
