What changed
Bun released version 1.4 on August 20 after moving the runtime and tooling implementation from Zig to Rust. The release adds 1,517 passing tests from Node.js's own test suite, targets Node.js 26.3 compatibility, fixes more than 2,900 issues according to the project, and expands the single binary with APIs that replace common dependencies including browser automation, image processing, Markdown, cron and terminal handling. Bun also reports materially lower startup time, memory and idle CPU use across its own test workloads. The migration is not compatibility-neutral: Bun now reports Node.js 26.3.0 and `NODE_MODULE_VERSION` 147, so native addons built for Node 24 must be rebuilt, and the project maintains an explicit 1.4 breaking-change tracker and upgrade guidance.
Why it matters
Bun's pitch has always been an integrated JavaScript toolchain, but 1.4 changes both the implementation foundation and how much application infrastructure can move into the runtime binary itself. Teams can potentially remove dependencies such as Puppeteer-style browser control, sharp-style image processing, cron helpers and terminal libraries from some workloads, while the Node-compatibility jump reduces another class of migration blockers. At the same time, a full implementation rewrite creates regression risk that ordinary semver expectations do not capture. Builders should therefore treat 1.4 as a runtime migration: test native modules, framework workloads, long-lived servers and build pipelines before broad rollout, and regard Bun's performance numbers as vendor benchmarks until they are reproduced independently.
The implementation moved from Zig to Rust
Bun 1.4 is the first stable release of the project's Rust port. That makes the release architecturally different from an ordinary feature train: the implementation language underneath the runtime, package manager, bundler and tooling has changed while Bun aims to preserve its external behavior. The project tracked regressions through the canary cycle, with most listed Rust-port issues closed before release but at least some platform-specific work still open.
Node compatibility took its biggest jump since 1.0
Bun says 1.4 adds 1,517 passing tests from Node.js's own test suite, its largest compatibility increase since Bun 1.0. The compatibility target is now Node.js 26.3.0. This matters for packages that gate behavior on Node versions, but it also changes the native-module ABI: `NODE_MODULE_VERSION` is 147, and addons compiled for Node 24 need to be rebuilt.
The binary absorbs more dependencies
The release expands Bun's built-in APIs with `Bun.WebView`, `Bun.Image`, `Bun.markdown`, `Bun.cron`, `Bun.Terminal`, JSON5, XML and archive helpers, plus parallel run/test commands. The practical value is not merely fewer installs: some applications can remove native or browser-automation dependencies and their update/build surface. `Bun.WebView`, for example, can drive system WebKit on macOS or an installed Chromium-family browser through CDP, while `Bun.Image` covers common image transformations without a separate native addon.
Performance claims are large but vendor-produced
Bun reports lower memory use across several server workloads, faster startup on Windows and Linux, five-times lower idle CPU use and smaller binaries on Linux and Windows. Its published table shows reductions such as Fastify memory falling from 233 MB to 120 MB and Next.js from 397 MB to 285 MB in the project's test setup. Those are useful signals, not neutral benchmarks: teams should reproduce them on their own traffic, frameworks, filesystems and host hardware before turning them into capacity assumptions.
The upgrade has real compatibility edges
Bun maintains a dedicated 1.4 breaking-change tracker. Beyond the Node ABI bump, x64 distribution changes remove the separate Haswell-targeted build in favor of baseline artifacts with runtime SIMD dispatch, and the upgrade work documents behavior changes accumulated during the Rust port. The project's regression tracker is also a reminder that a rewrite can surface workload-specific problems even after broad canary testing.