cloudparts

Nx

A monorepo build system that maps how the projects in a repository depend on each other, runs tasks in that order in parallel, reuses cached results whose inputs haven’t changed, and on CI runs only what a change can affect.

What it is
Build tools
Type
Open source
Made by
Narwhal Technologies, Inc.
License
MIT (Nx Cloud is a paid service)
Facts checked
13 October 2026

What it is

Nx starts by building a project graph. It finds projects from project.json files and from package.json files in your package manager’s workspaces, then works out which depends on which by reading source imports, installed packages and TypeScript configuration, caching the graph and re-reading only changed files. Tasks such as build, test and lint come from package.json scripts, project.json targets, or plugins that infer them from tool config: @nx/vite reads vite.config.ts and creates build, dev and preview tasks with their cache settings. A rule like "dependsOn": ["^build"] in nx.json says “build my dependencies first”, and from these Nx builds a task graph and runs independent tasks side by side.

Before running a task Nx hashes its inputs: the project’s files and its dependencies’ files, relevant config, external package versions, OS and CPU architecture, and the command-line arguments. If that hash is in the local cache, or in a remote cache when one is set up, Nx restores the declared output files and replays the terminal output instead of running the task. nx affected -t test goes one step further on CI: it asks Git which files changed, maps them to projects, adds every project that depends on those, and runs the task only there. Correctness depends on accurate inputs and outputs; a missing input gives a stale cache hit.

The core is open source under MIT, with parts written in Rust. It targets JavaScript and TypeScript first, but any project.json target can run any command with the same caching, and official plugins read Gradle, Maven and .NET projects (community ones cover Python, Go and Rust). nx release versions, writes changelogs for and publishes packages in the workspace. Nx Cloud, the company’s paid service, adds a hosted remote cache, distribution of tasks across CI machines (Nx Agents) and AI fixes for failed CI runs; a self-hosted cache can instead implement Nx’s published OpenAPI specification.

Why teams pick it

  • Computation caching at the process level: any task with declared inputs and outputs, not just builds, is skipped when nothing it reads has changed
  • nx affected and the project graph keep CI time proportional to the change rather than to the size of the repository
  • Plugins infer tasks and cache settings from existing tool config (Vite, Gradle, Maven, .NET and more), so adopting it in an existing repository needs little configuration
  • Module boundary rules with project tags stop unwanted imports between projects as the monorepo grows

Watch out for

  • Remote caching and task distribution are tied to Nx Cloud unless you build a server against the OpenAPI spec; Cloud’s Hobby tier includes 50,000 credits a month and 5 contributors, Team is $29 a month plus $19 per contributor and $5.50 per 10,000 credits
  • Wrong or missing inputs and outputs lead to stale cache hits or outputs that aren’t restored, and a change to a widely shared library still makes most of the repository “affected”
  • Frequent major versions (13 between December 2020 and June 2026) mean regular nx migrate runs, and Nx 16 moved every package from the @nrwl scope to @nx
  • A large npm dependency tree in your build path is attack surface: in August 2025 malicious nx versions published with a stolen npm token stole credentials from machines that installed them

Alternatives

What all build tools have in common →Compare side by side →

How it fits with other technologies

nx.json: build dependencies first, hash only production files, release packages · json

{
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"],
      "outputs": ["{projectRoot}/dist"]
    },
    "test": {
      "dependsOn": ["build"],
      "inputs": ["default", "^production"]
    }
  },
  "release": { "projects": ["packages/*"] }
}

Everyday commands#

The second nx build myapp with unchanged inputs is a cache hit and finishes without running the build.

bash
npx nx graph                       # open the project graph
npx nx run-many -t build test      # every project, in dependency order, in parallel
npx nx build myapp                 # one task (and the builds it depends on)
npx nx affected -t lint test build # only projects a change can affect
NX_LEGACY_AFFECTED=false npx nx affected -t build --explain
npx nx release --dry-run           # version, changelog, publish (preview)
npx nx@latest connect              # attach the workspace to Nx Cloud

See it in a real stack

No architecture uses Nx yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2026

Jeff Cross and Victor Savkin were engineers on Google’s Angular core team. Working inside Google’s large monorepo showed them how much a single repository could help teams, and how much tooling it took to make one work at scale. After leaving Google they founded Nrwl, which works with large companies on their monorepos, and started Nx to bring that kind of tooling to everyone, built in the open as an open-source product.

Nx began in 2017 as “Nrwl Extensions for Angular”, published as @nrwl/schematics and described as an open-source toolkit for enterprise Angular applications, with an opinionated structure for apps and libraries in one repository. Over the following years it became framework-agnostic: React, Node and other presets, a computation cache, the affected commands, and plugins for non-JavaScript stacks. In May 2022 Nrwl took over stewardship of Lerna, the older JavaScript monorepo tool, which had been largely unmaintained since 2020.

Nx 15 added Rust to the codebase to speed up core work and decoupled Nx versions from Angular’s, and Nx 16 (May 2023) moved every package from the @nrwl scope to @nx. In August 2025 an attacker used a vulnerable pull-request workflow in the Nx repository to steal its npm token and publish malicious versions of nx and several plugins that harvested credentials; the versions were removed from npm within hours, and the Nx team documented the root cause in a GitHub security advisory. Nx 23 came out in June 2026, and the latest release is 23.3.0 (October 7, 2026).

Why it’s built this way

Hash every input and cache any task’s output
In a large monorepo the same builds and tests run again and again with identical inputs. Treating each task as a computation keyed by the hash of its inputs lets Nx skip it locally, on CI and across machines, whatever tool it runs.
Derive the project graph from the code
Writing every dependency by hand doesn’t scale, so Nx reads imports, package manifests and TypeScript config itself and only asks you to declare the edges it can’t see. The same graph powers task ordering, affected runs and boundary rules.
Infer tasks from existing tool configuration
Tools like Vite already say where their output goes; plugins read that config so teams don’t repeat it in Nx files, which lowers the cost of adding Nx to an existing repository.

Timeline

  1. 2017

    Nrwl publishes @nrwl/schematics, “Nrwl Extensions for Angular” (September)

  2. 2020

    Nx 11 (December 11)

  3. 2022

    Nrwl takes over stewardship of Lerna (May 11)

  4. 2023

    Nx 16 (May 2): packages rescoped from @nrwl to @nx, Rust in the core since Nx 15

  5. 2025

    Malicious nx versions published with a stolen npm token (August), removed within hours

  6. 2026

    Nx 23.0.0 (June 16); 23.3.0 released October 7

Sources13 · facts checked 13 October 2026

Improve this page on GitHub