Nub is a single Rust binary that gives you a Bun-style developer experience on top of the stock Node.js you already run — TypeScript file execution, a pnpm-compatible package manager 18x faster than pnpm install, a script runner 24x faster than pnpm run, a bin runner 19x faster than npx, and a built-in Node version manager, all in one command. Created by Colin McDonnell (the creator of Zod) and launched in June 2026, it does something Bun and Deno deliberately do not: it augments Node.js instead of replacing it, which means no new runtime to maintain compatibility with, no vendor-specific APIs to learn, and zero lock-in.
TL;DR — Nub replaces six dev tools with one binary. TypeScript runner (replaces tsx/ts-node), script runner (24x faster than pnpm run), bin runner (19x faster than npx), package manager (18x faster than pnpm install, pnpm-compatible), Node version manager (replaces nvm/fnm), and watch mode (replaces nodemon). MIT licensed, 3.5k+ GitHub stars as of July 2026. No new runtime — it runs on your existing Node.js. GitHub · Docs
Last verified: 2026-07-30 · Pricing/limits/versions change often — last checked 2026-07-30.
What does Nub replace?
Nub folds seven categories of JavaScript tooling into one binary, each a tool you probably have installed separately today:
| Nub command | Replaces | Speed claim | Verified? |
|---|---|---|---|
nub index.ts |
tsx, ts-node, dotenv, tsconfig-paths | Negligible overhead over plain Node | Confirmed (vendor bench) |
nub run dev |
npm run, pnpm run | 24x faster than pnpm run | Confirmed (vendor bench) |
nubx prisma generate |
npx, pnpm exec/dlx | 19x faster than npx | Confirmed (vendor bench) |
nub install |
npm install, pnpm install | 18x faster than pnpm install | Confirmed (vendor bench) |
nub node install 26 |
nvm, fnm, volta | Auto-provisions Node on demand | Confirmed (docs) |
nub watch src/server.ts |
nodemon, node --watch | Dependency-graph-driven restarts | Confirmed (docs) |
nub pm shim |
corepack | Corepack-style shims in Rust | Confirmed (docs) |
The benchmarks above come from Nub's own repository (run with hyperfine on macOS), so treat them as vendor-reported numbers — the methodology is published and reproducible, but real-world gains depend on your machine, lockfile state, and dependency count. The speed wins are real and stem from a single architectural choice: Nub's CLI is a native Rust binary, so it avoids the JavaScript startup penalty that npm, pnpm, and npx pay every time they cold-load their own runtime just to dispatch a command.
How does Nub run TypeScript without a new runtime?
Nub transpiles your TypeScript in memory through oxc — a Rust-based JavaScript/TypeScript toolchain compiled into a native Node API addon — and then hands the output to the stock node binary to execute. There is no Nub runtime, no Nub global namespace, and no nub: import namespace. Your code runs on real Node's V8 engine and standard library. This is the core architectural bet: Bun and Deno implement Node's API surface from scratch (and inevitably get some of it wrong — Bun sits at roughly 77% Node.js compatibility per community testing); Nub rides on top of Node's own public extension surfaces (module.registerHooks(), --import preloads, and N-API native addons), so you inherit 100% of Node's compatibility for free.
The TypeScript runner supports full TypeScript — not just type stripping like native node --experimental-strip-types does. Enums, namespaces, parameter properties, decorators, JSX (transpiled based on your tsconfig), and the using keyword for explicit resource management all work. It also loads .env files automatically (with variable expansion like Vite and Next.js), resolves tsconfig path aliases, and polyfills modern Web APIs like Worker and Temporal on Node versions that lack them.
How fast is Nub's package manager?
Nub's installer is powered by the aube engine — a Rust package resolver created by JDX (the developer behind the mise version manager). On Nub's published benchmark (warm frozen install of TanStack Start, 313 dependencies, macOS), the numbers are:
| Tool | Install time | Relative |
|---|---|---|
| nub | 171 ms | — |
| bun | 686 ms | 4.0x slower |
| pnpm | 3,193 ms | 18.7x slower |
| npm | 5,316 ms | 31.1x slower |
Source: Nub benchmark repository (vendor-reported, hyperfine, macOS).
The CLI is flag-for-flag compatible with pnpm — every pnpm install flag works identically in nub install, including workspace catalogs, --filter, and monorepo commands. The critical difference from other "fast package managers" is that Nub does not force you into a new lockfile format. It auto-detects your incumbent package manager and reads/writes the lockfile you already have:
- npm projects: reads and writes
package-lock.json - pnpm projects: reads and writes
pnpm-lock.yaml - Bun projects: reads and writes
bun.lock - Yarn projects: reads
yarn.lock(read-only, no write-back)
This means a team using pnpm can drop in nub install and the pnpm-lock.yaml stays the format everyone expects. No migration, no .nub-lock.json, no lock-in. If you later remove Nub, your project is unchanged.
Is Nub's package manager supply-chain safe?
Nub ships with supply-chain defenses enabled by default — no configuration required. Three mechanisms are on out of the box:
Postinstall script blocking. Nub skips package build scripts during install by default, names which packages it skipped, and waits for you to run
nub approve-buildsto review and enable them. This blocks the most common supply-chain attack vector (malicious postinstall scripts) the way pnpm's--ignore-scriptsdoes, but transparently.Minimum release age. Nub enforces a default 24-hour cool-down on newly published packages, so a freshly published malicious version cannot enter your dependency tree the moment it hits npm.
Advisory checking. During resolution, Nub checks osv.dev for known-malicious package versions and refuses provenance downgrades by default.
These match pnpm's security posture but are defaults rather than opt-in flags — a meaningful difference for teams that never configured pnpm's security settings.
How does the script runner achieve 24x speedup?
When you run npm run build or pnpm run build, the package manager boots a Node.js process, loads its own JavaScript runtime (config parsing, workspace detection, etc.), and only then dispatches your script. That cold-start overhead is 300–450ms per invocation on macOS. Nub's script runner is a Rust binary with no JavaScript startup of its own — it resolves the script from package.json and execs it directly, clocking 14.7ms on the warm dispatch benchmark:
| Tool | Script dispatch | Relative |
|---|---|---|
| nub run | 14.7 ms | — |
| node --run | 32.2 ms | 2.2x slower |
| npm run | 329.9 ms | 22x slower |
| pnpm run | 442.7 ms | 30x slower |
Source: Nub script-runner benchmark (vendor-reported, 50 warm runs, macOS).
The script runner is flag-for-flag compatible with pnpm run, including --filter grammar for monorepos, recursive runs (-r), --parallel, --no-bail, and argument forwarding (nub run test -- --coverage). Your existing CI scripts work unchanged after swapping pnpm for nub.
How do you install and use Nub?
Nub is MIT-licensed and installs in one command on macOS, Linux, and Windows:
# macOS / Linux
curl -fsSL https://nubjs.com/install.sh | bash
# or via npm
npm install -g @nubjs/nub
# or via Homebrew
brew install nubjs/tap/nub
Once installed, the commands map directly to the tools they replace:
nub index.ts # run a TypeScript file (replaces tsx/ts-node)
nub install # install dependencies (pnpm-compatible)
nub run dev # run a package.json script (replaces npm/pnpm run)
nubx prisma generate # run a CLI from node_modules/.bin (replaces npx)
nub watch src/server.ts # watch mode with auto-restart (replaces nodemon)
nub node install 26 # install Node.js 26 (replaces nvm/fnm)
nub pm shim # register Corepack-style shims for npm/pnpm/yarn
For CI, Nub provides a GitHub Action (nubjs/setup-nub) that replaces actions/setup-node — it installs Nub, warms the project's Node version, and caches Nub's store in a single step.
Nub vs Bun: which should you use?
The comparison matters because both tools target the same pain point — a fragmented Node.js developer experience — but take opposite architectural bets:
| Dimension | Nub | Bun |
|---|---|---|
| Runtime | Stock Node.js (V8) | Custom runtime (JavaScriptCore, Zig) |
| Node.js compatibility | 100% (it IS Node) | ~77% (reimplements Node APIs) |
| Language | Rust | Zig + V8 |
| TypeScript | oxc transpiler (N-API addon) | Built-in (type stripping / SWC) |
| Package manager | aube engine (pnpm-compatible) | bun install (npm/yarn/pnpm-compatible) |
| Lock-in | None — code runs on plain Node | Medium — Bun runtime APIs, Bun.serve, etc. |
| Native modules | Full Node.js N-API support | Partial (some Node addons break) |
| Production runtime | Still run compiled JS on Node | Run on the Bun runtime |
| Best for | Node teams who want speed without risk | Teams adopting a full new stack |
The key trade-off: Bun delivers more — a bundler, test runner, SQLite driver, WebSocket server, Bun.write — but you adopt those as Bun-specific APIs that only work on the Bun runtime. Nub delivers less surface area but zero lock-in: every file you run with Nub also runs on plain node after compilation, every package.json script works with or without Nub, and there is no Nub-specific config file or global namespace.
For teams already invested in the Node.js ecosystem (especially those with native addons, existing CI pipelines, or strict compatibility requirements), Nub is the lower-risk path to faster development. For greenfield projects that want the maximum performance and tightest integrated stack, Bun is still the stronger option.
What this means for you
If you maintain a Node.js codebase and your development loop involves waiting on pnpm install, watching npm run eat 300ms before your script even starts, or juggling tsx + dotenv + tsconfig-paths + nodemon as separate dependencies — Nub collapses all of that into one binary you can adopt incrementally. Start with the script runner or package manager in a single project; if it works, expand. If it doesn't, remove it — your project's lockfile and Node version are unchanged. That zero-migration story is Nub's real differentiator, not the raw benchmarks.
For small teams building with AI coding agents, faster CLI dispatch translates directly to faster agent iteration loops. An agent running nub run test instead of npm run test saves hundreds of milliseconds per command — multiplied across dozens of test runs in a feature build, that compounds. If you are already setting up an AI agent fleet for development, adding Nub to the base image is a one-time win that pays on every tool call.
How does Nub compare to tsx and ts-node for TypeScript execution?
Nub is a superset of what tsx and ts-node do. It transpiles TypeScript via oxc (faster than tsx's esbuild-based approach), supports full TypeScript syntax (enums, namespaces, decorators — which tsx and node --experimental-strip-types do not), auto-loads .env files (replacing dotenv), resolves tsconfig path aliases (replacing tsconfig-paths), and provides a native watch mode (replacing nodemon). The overhead over plain Node is negligible per the vendor benchmark, and because it runs on stock Node, you get full N-API native module support — something tsx does not add but does not guarantee either. The practical upshot: nub index.ts replaces four packages and a config file with one binary.
Does Nub work with monorepos?
Yes. The script runner and package manager both support pnpm's full --filter grammar and recursive (-r) execution. nub -r run build runs every package's build script in topological order. nub --filter @org/api dev runs the dev script in a single workspace package. nub --filter ...@org/web build runs build in @org/web and all its dependencies. The package manager reads pnpm-workspace.yaml and package.json workspaces, so existing monorepo layouts work without changes.
Can you use Nub in production?
Nub is explicitly positioned as a development toolkit, not a production runtime. In production, you should still compile your TypeScript to JavaScript and run it on plain node. Nub does not type-check your code (you still need tsc --noEmit in CI), and the project launched in June 2026 — the ecosystem and plugin surface are still maturing. Use Nub for local development, CI script execution, and monorepo tooling. For production serving, the stock Node.js runtime remains the deployment target.
Is Nub free and open source?
Yes. Nub is MIT-licensed and the entire source is on GitHub at nubjs/nub. As of July 2026 it has over 3,500 GitHub stars. The project is maintained by Colin McDonnell (creator of Zod) and Sam Bhavsar (creator of ts-based entities-type packages), with the package manager engine (aube) maintained by Jeff Davenport (JDX, creator of mise).
FAQ
Q: What is Nub? A: Nub is an all-in-one Rust-powered toolkit for Node.js that provides a TypeScript file runner, pnpm-compatible package manager, script runner, bin runner, watcher, and Node version manager in a single binary. It augments stock Node.js instead of replacing it, so there is no new runtime to adopt and no lock-in.
Q: Who created Nub? A: Colin McDonnell, the creator of Zod — the most popular TypeScript-first schema validation library. He previously worked at Bun, giving him direct experience with the alternative-runtime approach Nub deliberately avoids. The project launched in June 2026.
Q: Is Nub faster than Bun? A: On the package manager benchmark, Nub installs 4.0x faster than Bun (171ms vs 686ms for 313 deps, vendor-reported). However, Bun is a complete runtime with a bundler, test runner, and native APIs that Nub does not provide. The speed comparison applies to the toolchain layer (install, script dispatch, bin execution), not runtime execution of your application code.
Q: Does Nub replace pnpm?
A: Nub is flag-for-flag compatible with pnpm and reads/writes your existing pnpm-lock.yaml in place — so it can replace pnpm as your CLI without migrating your lockfile. If you later decide to remove Nub, your pnpm lockfile and config are untouched.
Q: What Node.js versions does Nub support?
A: Nub runs on Node.js 18 LTS and newer. It transpiles TypeScript through its native oxc addon and executes the output on the stock node binary your project already uses. The built-in version manager can auto-install any Node version from nodejs.org on demand.
Q: Is Nub production-ready? A: Nub is positioned as a development toolkit, not a production runtime. For production, compile your TypeScript to JavaScript and run it on plain Node. The project launched in June 2026 and reached v0.2.1 within weeks — functional but still early-stage. Use it in development and CI; keep stock Node for production serving.
Discussion
0 comments