Bun 1.4 ships in Rust: the numbers and what breaks

Three months of nothing, then it lands. Bun 1.4 went stable on 20 August, the first shipped release since the team tore the runtime out of Zig and rebuilt it in Rust, and the honest summary is that it's meaningfully faster and it will trip a few projects on the way in. Server memory drops somewhere between 13 and 48 percent depending on what you run. Startup is half again quicker on Linux. But Bun's own release notes flag five behaviour changes as the ones most likely to need a line in your project, and one of them is a YAML parser fix that turns the `on:` key in your GitHub Actions workflow into a plain string. We read the whole thing. Here's what's worth your afternoon.

The five that will bite you

Bun lists them under a heading called Upgrading to 1.4, and the framing is refreshingly blunt: most code is unaffected, five changes are the ones most likely to need a line in your project. We’d rank them by how quietly they fail.

Top of that list, easily, is YAML. Bun.YAML now follows YAML 1.2, which means yes, no, on and off parse as strings rather than booleans. Bun spells out the consequence itself: on: in a GitHub Actions workflow now parses as the string "on". If you have tooling that reads workflow files and branches on that key, it stops matching and it does not throw. Silent. That’s the worst kind.

Then the Node.js 26 jump. Bun now reports process.versions.modules as 147, so any package that picks a prebuilt native addon by NODE_MODULE_VERSION needs a build for 147 or it falls over at require time. res.writeHeader() is gone from node:http, replaced by res.writeHead(). And in paused mode, readable.read() with no size argument returns a single buffered chunk rather than draining.

The other two are quieter. New monorepos default to the isolated linker and record configVersion: 1 in bun.lock, though existing lockfiles keep the hoisted behaviour, and you pin linker = "hoisted" in bunfig.toml to opt out. And Bun invoked as node, meaning bun --bun, bunx --bun or a node symlink, no longer loads .env files. That one matches Node’s actual behaviour, so it’s a correctness fix, but it will absolutely surprise someone whose CI leans on it. Pass --env-file.

Honestly, if you only audit one thing before upgrading, make it the YAML change.

The numbers, and where they came from

Bun’s headline claims are 5x lower idle CPU, up to 35 percent less memory, 50 percent faster startup on Linux, plus 1,517 new Node.js test-suite tests and over 2,900 issues closed. Marketing rounds those up. The detail underneath is more interesting than the summary.

Memory is measured as peak usage under load, a million requests over 64 connections, and the reduction is nowhere near uniform. Fastify falls from 233 MB to 120 MB. Express goes 169 to 92. Bare node:http drops 135 to 81. But the Vite dev server only improves from 268 MB to 233 MB, about 13 percent, and Next.js lands at 285 MB from 397. So the gain scales with how much of your process is actually Bun rather than your framework’s own allocations. Makes sense, and it’s good that they published the losers alongside the winners.

The number we found most persuasive isn’t a benchmark at all. Bun reports that Claude Code, a large long-running app that already ships on Bun, saw production CPU halve: p99 from 24 percent to 10 percent, p50 from 5.8 percent to 2.5 percent. That’s a real workload with real users, not a hello world loop, and it lines up with the native Bun build we wrote about in July.

Node compatibility got specific too. node:events, node:trace_events and node:sqlite now pass 100 percent of Node’s tests. node:quic passes 99. A cluster of the big ones including node:http, node:fs and node:stream sit at 97. Bun also reports Node-API version 10 with headers synced from Node 26.

The new APIs worth a look

Bun.WebView is the one people will play with first. Headless browser automation in the runtime, driving either macOS WebKit or a local Chromium over the DevTools Protocol, with no Puppeteer install. Simon Willison had a working screenshot and JavaScript evaluation API out of it in roughly 150 lines of TypeScript and zero dependencies. His caveat matters though: driving full Chrome against complex pages wanted a 192 MB to 256 MB container. The dependency moved, it didn’t disappear.

Bun.cron() is sneakier and I think more useful. It registers a job with the operating system itself, crontab on Linux, launchd on macOS, Task Scheduler on Windows, and your script exports a scheduled(controller) handler shaped exactly like a Cloudflare Workers Cron Trigger. Standard five-field syntax, named days, @daily. For small boxes where you’d otherwise hand-write a systemd timer, that’s a genuine subtraction of work.

Then the housekeeping. Bun.Image does decode, resize and encode in-process, claimed 1.38x faster than sharp with nothing to install. bun audit fix upgrades vulnerable packages and installs, telling you when a fix needs a major bump. bun dedupe and bun prune do what they say. bun run --parallel and bun test --parallel spread work across processes.

Windows users get a genuinely odd win: setTimeout(fn, 1) now fires in about 1.4 ms instead of 15.5 ms, because timers stopped rounding to the 15.6 ms system tick. Bun also runs inside a Windows AppContainer now. HTTP/3 in Bun.serve() and HTTP/2 with HTTP/3 in fetch() both ship, both explicitly experimental, and Bun’s own note says don’t put http3: true in production yet. The release also declares itself ready for TypeScript 7, which pairs with the Go-native compiler rewrite.

The Rust question is still open

Here’s where we’d push back on the celebration. The rewrite was pitched on memory safety: Zig kept producing use-after-free and double-free bugs, and Rust’s ownership model catches that class at compile time. Fine. But the release notes lead with performance, and performance was never the stated reason.

Developer Tero Piirainen went through the repository before the release and counted, in a single month, 15.8k commits from the robobun account, 1.6k from an autofix bot and 790 from Bun’s lead. Over 5,000 open pull requests. His read is that the volume of unsafe blocks in the new Rust undercuts the safety argument that justified the whole exercise, and he’s sharper than that in print, arguing the choice was made first and Zig’s memory issues used as the reason afterwards.

I might be wrong here, but I don’t think that argument gets settled by shipping. It gets settled by a year of production. What we can say is that Bun 1.4 is already running under Claude Code at scale, with published CPU numbers going the right way, and that’s a stronger signal than a changelog.

Our advice is boring. Upgrade a side project this week, grep your workflow tooling for anything that reads on: out of a YAML file, and check whether any native addon in your tree ships a prebuilt for NODE_MODULE_VERSION 147. If those come back clean, the memory numbers are worth having.

Image: Bun, announcement card from the Bun 1.4 release post.

Sources

The release date, the upgrade command, the 1,517 added Node.js tests, the 2,900 issues, the 5x idle CPU and 50 percent Linux startup claims, the per-framework memory table, the Claude Code p99 and p50 CPU figures, the Node module pass rates, the five upgrading notes and every new API described here come from Bun’s own release post, Bun 1.4, published 20 August 2026. The Bun.WebView prototype, the 150-line figure and the 192 MB to 256 MB container requirement come from Simon Willison, A shot-scraper-style JSON API on Bun 1.4’s new Bun.WebView. The commit counts, the open pull request figure and the criticism of the review trail come from Tero Piirainen, Bun 1.4 Rust rewrite is not looking good. Every performance figure here is vendor-reported and we have not independently reproduced any of it.

Frequently asked questions