Bun 1.4 Ships the Rust Rewrite: What's Actually New and What's Still Shaky

Bun 1.4 shipped August 20, and the headline feature isn’t a new API, it’s the ground underneath all of them. This is the first stable Bun release running entirely on the Rust runtime the team has been rewriting from Zig since May. Underneath that, it adds real capability: built-in browser automation, image and markdown processing, a handful of new APIs that used to mean an npm install, and performance numbers that, if they hold up outside Bun’s own benchmarks, are worth paying attention to. It also shipped after the longest gap between stable releases in Bun’s history, and the rewrite itself became a minor community controversy on the way out the door. Both things are true at once, and worth separating.

The rewrite, in short

Bun’s runtime was originally written in Zig. The team began moving the core to Rust in May 2026, aiming for stronger memory safety guarantees than Zig’s manual memory management provides by default. The initial rewrite commits were enormous, over a million lines added across more than 2,000 files, and a large share of that code was produced with heavy AI assistance rather than written and reviewed line by line the traditional way.

That’s not inherently disqualifying. Plenty of large refactors get AI assistance now, and the resulting code either works or it doesn’t. But the scale, combined with a release cadence that slipped for months (creator Jarred Sumner’s own public timeline estimates kept moving), left prominent community voices skeptical. Tero Piirainen, a longtime Bun advocate, wrote pointedly that the project had drifted into “continuous false promises and an increasingly frustrated community” during the gap. Bun’s open PR count also climbed past 5,000, well beyond what a healthy repository queue looks like, with a large fraction coming from automated commits. None of that means Bun 1.4 doesn’t work. It does mean the usual “wait a couple of point releases before trusting a major runtime change in production” advice applies more than usual here.

What’s actually new

Beyond the runtime swap, Bun 1.4 adds a real batch of built-in APIs:

API	What it replaces
Bun.WebView	Playwright/Puppeteer for simple automation, via WebKit (macOS) or CDP-controlled Chromium
Bun.Image	sharp for basic image resize/format operations
Bun.markdown	marked or remark for markdown-to-HTML
Bun.cron()	node-cron or a system crontab entry for in-process scheduling
Bun.Terminal	node-pty for terminal emulation
JSON5 / JSONL parsing	json5 and manual line-by-line JSONL handling

Bun.WebView is the one worth a closer look. It exposes browser automation directly from the runtime, either driving native WebKit on macOS or controlling a local Chromium process over the Chrome DevTools Protocol:

import { WebView } from "bun";

const view = new WebView({ headless: true });
await view.goto("https://example.com");
const title = await view.evaluate(() => document.title);
const screenshot = await view.screenshot();
await view.close();

It’s not a Playwright replacement for teams that need cross-browser test coverage across Firefox and WebKit and Chromium with managed binary downloads. It is a real option for the much more common case: a script or an agent that needs to load a page, extract something, or take a screenshot, without adding a dependency that pulls in its own browser binaries.

The CLI got attention too: bun run --parallel and bun test --parallel run multiple scripts or test files concurrently, bun audit fix applies fixable advisories automatically, and bun dedupe / bun prune clean up the dependency tree without reaching for a third-party tool. There’s also an opt-in global virtual store for package installs, which Bun claims gets up to 7x faster installs on repeat runs by sharing a package cache across projects instead of copying into each node_modules.

The performance numbers

Bun’s own release post gives these figures for the Rust runtime versus the prior Zig build: idle CPU usage down roughly 5x, memory usage down by up to 35%, and startup time on Linux improved by about 50%. Node.js compatibility also improved, with 1,517 additional tests from Node’s own test suite now passing under Bun, plus native Windows ARM64 support for the first time.

Treat vendor-published multipliers the way you’d treat any first-party benchmark: directionally useful, not a promise your specific workload will see the same ratio. The idle-CPU number in particular is easy to verify yourself with a quick bun --hot dev server running next to htop, and worth doing before you cite it in your own upgrade justification.

Should you upgrade from 1.3?

If you’re running Bun 1.3’s built-in SQL and Redis clients already, the 1.4 upgrade doesn’t touch that surface. Bun.sql and the native Redis client aren’t part of this release’s changes, so existing code keeps working as-is. The new APIs are additive, not replacements you’re forced to migrate to.

The real question is how much you trust a runtime the week after it finished swallowing a from-scratch rewrite of its core. For a side project or an internal tool, upgrade now and get the CPU and memory wins. For anything customer-facing and latency-sensitive, give it a couple of point releases, watch the GitHub issue tracker for regressions specific to your workload (WebSocket handling and native module compatibility are the areas that tend to surface Rust-rewrite edge cases first), and upgrade deliberately rather than as part of a routine dependency bump. If runtime choice itself is still an open question for your stack, the Bun vs. Deno vs. Node comparison is worth revisiting now that the rewrite has actually shipped rather than just been promised.

The features are real and mostly land where developers have been asking for them, fewer dependencies, faster cold starts, less CPU burned idling. Whether the process that produced them changes how much scrutiny the next Bun release gets is a separate question, and one the community clearly isn’t finished asking.