Nx is an MIT-licensed monorepo platform for TypeScript and polyglot codebases that caches unchanged work, runs only affected tasks, and ships an integrated CI solution aimed at both developers and autonomous AI agents.

What it is

Nx is a monorepo solution for TypeScript and polyglot codebases. The project lives in the JavaScript and TypeScript ecosystem, its core is built with Rust for performance, and it is extensible via TypeScript. Distribution is through the nx CLI, with roughly 29,347 stars, 2,999 forks, and 490 open issues on GitHub, and a homepage at nx.dev.

The concrete problem it solves is the orchestration of many packages and scripts inside one repository. In a plain npm, pnpm, or yarn workspace, a change to one library forces teams to rewire package.json scripts by hand and to rebuild or retest far more than the change touched. Nx replaces that manual script wiring and the naive full-workspace run: running npx nx init in an existing workspace makes Nx pick up the existing package.json scripts, cache their outputs, and run only the tasks affected by a change, with no changes to the existing setup required.

Key capabilities

• Zero-migration adoption through npx nx init, which initializes Nx inside any existing npm, pnpm, or yarn workspace and reuses the package.json scripts already present.
• Output caching tied to tasks, so work that did not change is skipped and only affected targets run.
• A polyglot plugin system where optional plugins auto-discover tasks, configure cache inputs and outputs, and scaffold code based on the tooling actually in use.
• Plugin coverage across Vite, Webpack, Jest, Vitest, ESLint, Gradle, Maven, .NET, and Go, with more listed at nx.dev/technologies.
• An integrated CI solution that connects to GitHub Actions, GitLab, Azure, and others to enable remote caching, task distribution across machines, affected-only runs, and automatic e2e test splitting.
• Self-healing CI: an AI agent on the pipeline detects failures, analyzes root cause, proposes a fix, and verifies it automatically.
• AI-native tooling: the Nx CLI is built so autonomous agents get the context they need, and local agents connect to CI over MCP to detect and fix failures.

Who uses it and how

• Product engineering teams running a single repository across many applications and libraries, from startups to Fortune 500 companies.
• Polyglot organizations that mix JavaScript and TypeScript with Gradle or Maven, .NET, or Go code and need one task graph over all of it.
• CI owners on GitHub Actions, GitLab, or Azure who want remote caching, task distribution across machines, and affected-only runs instead of rebuilding everything per pull request.
• Angular, Next.js, and Node.js projects, which appear among the project's topics alongside monorepo, build-system, and CLI concerns.
• Teams experimenting with agent-driven maintenance, where a local agent connects to the CI pipeline over MCP and acts on failures autonomously.

Getting started

Run npx nx init inside an existing npm, pnpm, or yarn workspace; Nx adopts the current package.json scripts without requiring setup changes. The Nx quickstart documentation at nx.dev/docs/quickstart covers the same path.

How it compares

No competing products are named in the facts for this listing, so Nx stands alone in this registry. The tools it is documented to work with, such as Vite, Webpack, Jest, Vitest, ESLint, Gradle, Maven, .NET, and Go, are plugin integrations rather than alternatives it replaces. Nothing is provided here that contrasts it with paid build or CI products on licence, hosting, data ownership, or cost.

When to use it — and when not to

A self-hosting team adopting the integrated CI features must connect Nx to its own CI provider and run the infrastructure for remote caching, task distribution, and agent-driven fix verification, and the starting point assumes a repository already organized as an npm, pnpm, or yarn workspace. Teams without a multi-package repository, or without a need for affected-only runs, will carry the cost of a plugin and task graph configuration for little gain. The excerpt available here is short and quotes no version or release cadence, and the repository carries 490 open issues, so a prospective adopter should check current release notes before committing to it.