Bun

Bun is a single executable that bundles together everything a JavaScript or TypeScript project usually needs several separate tools for: a runtime, a bundler, a test runner, and an npm-compatible package manager. It positions itself as a drop-in replacement for Node.js, running most existing Node.js and npm packages with little or no modification while executing .ts/.tsx files directly, without a separate build step.

Under the hood, Bun is written primarily in Rust with C++ for the JavaScriptCore bindings, and it embeds WebKit’s JavaScriptCore engine rather than V8. This is a significant architectural fact worth noting explicitly: Bun’s core was originally written in Zig, but the project has since completed a full migration to a Cargo workspace of roughly 200 Rust crates, with C++ retained only for the JavaScriptCore/WebKit integration layer. The GitHub-reported primary language and the project’s own CLAUDE.md both confirm Rust as the current implementation language.

Beyond the runtime, Bun ships a native bundler (Bun.build) that handles JS/TS/JSX/CSS/HTML with tree-shaking and code-splitting as a faster alternative to esbuild or webpack; a Jest-API-compatible test runner (bun test) built into the binary; and a package manager (bun install) with its own binary lockfile, workspaces, catalogs, and patch support. It also includes less common built-ins such as a cross-platform embedded POSIX-like shell (Bun.$), native SQLite/Postgres/MySQL clients, WebCrypto and node:crypto implementations, and the ability to compile a project into a single dependency-free executable with bun build --compile.

The project is backed by Oven and has grown into one of the most active runtime projects on GitHub, with a large BuildKite-driven CI pipeline that includes clippy, Miri, ASAN builds, and cross-platform smoke tests across Linux, macOS, and Windows on x64 and arm64.

What You Get

• A Node.js-compatible JavaScript/TypeScript runtime that executes .ts/.tsx files directly with no separate transpile step.
• A native bundler (Bun.build) for JS, TS, JSX, CSS, and HTML with tree-shaking, code-splitting, and single-file executable compilation.
• A built-in, Jest-API-compatible test runner (bun test) with snapshot testing, requiring no additional install.
• An npm-compatible package manager (bun install) with a binary lockfile, workspaces, dependency catalogs, and an isolated-install mode.
• A cross-platform embedded shell (Bun.$) for writing POSIX-like shell scripts that behave identically on macOS, Linux, and Windows.
• Native implementations of Web APIs (fetch, WebSocket, streams) and Node APIs (fs, path, Buffer, crypto), plus first-class SQLite/Postgres/MySQL clients.

Common Use Cases

• Replacing ts-node/nodemon plus a separate bundler and Jest with a single bun binary to shorten the local dev feedback loop.
• Swapping npm ci and node for bun install and bun run in CI pipelines to reduce build and test time on every pull request.
• Compiling a TypeScript CLI into one standalone executable with bun build --compile for distribution without requiring a Node.js install on the target machine.
• Writing HTTP servers and database-backed APIs directly against Bun.serve and Bun’s built-in SQL/SQLite clients without pulling in a separate web framework.
• Managing multi-package monorepos with Bun’s workspaces, catalogs, and lockfile instead of npm, Yarn, or pnpm.

Under The Hood

Architecture Bun is a Cargo workspace of roughly 200 Rust crates rooted at Cargo.toml, layered around a small set of foundational crates — bun_core (strings, formatting, logging, feature flags), sys (cross-platform syscall wrappers), and collections/threading/paths — that everything else builds on. The bun_bin crate is the actual entry point: its lib.rs documents an explicit six-step init order (crash handler, mimalloc global allocator wiring, argv capture, stdio init, stack-check configuration, then cli::Cli::start()), and the file is annotated with cold-path optimization notes showing real attention to startup latency. Above that foundation sit clearly separated subsystems — js_parser/js_printer/transpiler for JS/TS handling, resolver for module resolution, bundler for the native bundler, install for the package manager, runtime/server for Bun.serve, runtime/node for Node compatibility, and jsc/jsc/bindings as the sole boundary where Rust and hand-written C++ meet JavaScriptCore. This is a genuinely layered architecture: changing the JSC binding layer would ripple everywhere, but changing, say, the bundler’s CSS handling stays contained to src/css and src/bundler.

Tech Stack The core is Rust (pinned to a specific nightly toolchain in rust-toolchain.toml) with C++ used only for JavaScriptCore bindings (src/jsc/bindings); TypeScript is used both for Bun’s built-in JS modules (src/js/) and for the build/codegen tooling itself. The runtime embeds WebKit’s JavaScriptCore engine (vendored from an oven-sh/webkit fork) rather than V8, and statically links a substantial set of vendored C/C++ libraries — boringssl, brotli, c-ares, libarchive, libuv, lolhtml, mimalloc, zlib-ng, zstd, and more — configured through scripts/build/deps/*.ts. Native compilation runs through CMake and Ninja rather than a plain Cargo build, orchestrated by scripts/build.ts, and code generation (src/codegen/generate-classes.ts and friends) turns .classes.ts definitions into the matching Rust and C++ bindings automatically as part of that build.

Code Quality Testing is extensive: the test/ directory contains well over a thousand *.test.ts files organized by concern (test/js/bun, test/js/node, test/js/web, test/cli, test/bundler, test/napi, test/v8, test/regression), all run through Bun’s own Jest-compatible runner rather than an external framework. CI enforces this with dedicated Clippy and lint workflows, a Miri workflow for undefined-behavior detection on FFI-free crates, and ASAN/leak-sanitizer build profiles referenced directly in the binary crate’s allocator configuration. The project’s own contributor documentation (CLAUDE.md) codifies an unusually detailed internal style guide covering memory-safety patterns (RAII pairing, exception-check discipline around JavaScriptCore calls, cross-thread ownership rules) and test-writing conventions (hermetic tests, no setTimeout-based waits, draining subprocess pipes concurrently), which strongly suggests these practices are enforced in review rather than aspirational.

What Makes It Unique The standout technical decision is the full migration of Bun’s core from Zig to Rust while keeping JavaScriptCore as the engine — a large-scale rewrite that most projects of this profile never attempt post-launch. On top of that, Bun implements its own JavaScript/TypeScript parser and printer, its own module bundler and CSS processor, and a cross-platform shell interpreter, rather than wrapping existing tools like esbuild, Babel, or dash — giving it comprehensive control over startup time and behavior consistency across the runtime, bundler, and test runner. The standalone_graph module, which embeds an application plus the Bun runtime into a single self-contained executable, and the built-in native SQL/SQLite clients are further examples of functionality that competitors typically require separate packages or services for.

Self-Hosting

Licensing Model Bun itself is MIT licensed. It statically links WebKit’s JavaScriptCore engine, which is LGPL-2 licensed; per LGPL-2 obligations, the project publishes the patched WebKit fork it links against (oven-sh/webkit) and documents the exact steps to relink it in LICENSE.md, so self-hosters retain the right to rebuild against a modified engine.

Self-Hosting Restrictions None found. There is no ee/, enterprise/, pro/, or cloud/ directory in the source tree, and no license-key or feature-flag gating (isPro, isEnterprise, requiresLicense) anywhere in the Rust or C++ code. Every subcommand — runtime, bundler, test runner, package manager, and shell — ships in the same open-source build.

Enterprise Features Not applicable. The bun binary has no separate paid tier. Oven, the company behind Bun, operates the bun.com site and Discord, but its homepage promotes only the free, open-source toolkit; there is no pricing or enterprise page for the CLI itself.

License Key Required No.