On this page · 11 sections
Summary. Bun v1.4.0 was published to npm at 14:14 UTC on 20 August 2026 and tagged on GitHub at 14:07 UTC the same day. It is the first release of Bun written in Rust rather than Zig, and it arrived 99 days after v1.3.14 on 13 May 2026, the longest gap between stable Bun releases since the project started. The release post claims 2,900 issues fixed, 1,517 newly passing Node.js tests, idle CPU down 5x and memory down "up to 35%". It also changes five defaults that will break running code. Within 90 minutes of the tag, users filed a regression against the WebSocket shim; by the end of the day 20 issues were open against the release. Vercel, which added Bun 1.4 support to Vercel Functions on the same date, made the upgrade opt-in and told teams to read the breaking changes first. Jarred Sumner, creator of Bun, has disclosed that the port was produced by roughly 64 Claude agents over 11 days at a pre-merge cost of about $165,000 in API tokens, and that it introduced 19 known regressions.
If you run Bun in production, the version number is the least interesting thing in this release. The interesting part is the gap between what the release post leads with and what its own tables, its companion post and its issue tracker say.
What actually changed on 20 August
Bun v1.3.14, published 13 May 2026, was the last version written in Zig. The Rust port was merged to main on 14 May 2026 and then sat unreleased for three months. The Bun 1.4 announcement is the first stable build of that port.
The engineering claims in the post are specific and mostly benchmark-backed. Peak memory under load, measured at 1,000,000 requests with 64 connections, drops across every server the team tested.
| HTTP server | Peak memory, Bun 1.4 | Peak memory, Bun 1.3 |
|---|---|---|
| fastify | 120 MB | 233 MB |
| Express | 92 MB | 169 MB |
| node:http | 81 MB | 135 MB |
| Elysia | 55 MB | 91 MB |
| Next.js | 285 MB | 397 MB |
| Bun.serve | 36 MB | 45 MB |
| Vite dev server | 233 MB | 268 MB |
Startup improves too: 5.1 ms on Linux against 10.9 ms for Bun 1.3 and 27.2 ms for Node, and 15.5 ms on Windows against 39.0 ms and 40.1 ms. The minimum glibc requirement drops from 2.26 to 2.17, so Bun now runs on RHEL 7, CentOS 7 and Amazon Linux 1 without a separate build, and the documented minimum Linux kernel is now 3.10. FreeBSD 14.3+ gets official x86_64 and aarch64 binaries. Windows on ARM64 builds natively.
None of that is what will page your on-call engineer.
The five breaking changes
Bun's own upgrade section names five changes as the most likely to need work. Each maps to a concrete failure mode.
| Change | What breaks | What to do |
|---|---|---|
Bun now reports Node.js 26, process.versions.modules is 147 |
Prebuilt native addons selected by NODE_MODULE_VERSION have no build for 147; res.writeHeader() is gone |
Rebuild native modules for ABI 147; replace res.writeHeader() with res.writeHead() |
New monorepos default to the isolated linker, bun.lock records configVersion: 1 |
Hoisting assumptions in existing tooling stop holding for newly created workspaces | Pin linker = "hoisted" in bunfig.toml if your build depends on hoisted layout |
Bun invoked as node does not load .env files |
bun --bun, bunx --bun and node symlinks silently lose environment config |
Pass --env-file explicitly in every affected script |
Bun.YAML follows YAML 1.2 |
yes/no/on/off parse as strings, so on: in a GitHub Actions workflow becomes the string "on" |
Quote booleans, or read workflow keys by string |
Bun.TOML and bunfig.toml are strict |
Unquoted strings, missing newlines between pairs and integers past Number.MAX_SAFE_INTEGER now raise SyntaxError |
Validate config files before deploying 1.4 |
Beyond those five, the release removes the separate -march=haswell x64 build, removes the bun feedback command, makes fs.rmdir({ recursive: true }) throw ERR_INVALID_ARG_VALUE, silently ignores Bun.serve({ inspector }), and changes .xml imports to return a parsed document instead of a file path. Temporal and Date.prototype.toTemporalInstant are now defined by default, which is welcome if you have been tracking the Node.js 26 Temporal migration, and disruptive if you shipped a polyfill that assumed they were absent.
The change most likely to bite quietly is the third one. An environment file that stops loading does not throw. It produces a service that starts, connects to the wrong database, and looks healthy.
What the release post does not say
The 20 August release post has no known-regressions section. The words "regression", "not yet supported" and "parity" do not appear in it, and "Zig" appears exactly once, in the headline sentence.
The companion post published on 8 July, Rewriting Bun in Rust, is more candid. Jarred Sumner, creator of Bun, writes there: "The focus of the Rust rewrite is stability, but it would be impossible to ship a massive change like this and introduce zero regressions. This rewrite introduced 19 known regressions, each of which has been fixed." The same post discloses that Bun was acquired by Anthropic in December 2025, that the port took 11 days across 6,778 commits, that about 64 Claude agents ran at peak, that the merged diff was +1,009,272 lines, and that the pre-merge token spend was "around $165,000 at API pricing". It also reports that about 4% of Bun's Rust code sits inside unsafe blocks, roughly 13,000 unsafe keywords across some 27,000 lines.
That candour is in the July post. It is not in the August one, which is the post most teams will read before upgrading.
The headline numbers understate the body numbers in one direction and overstate them in another.
| Headline claim | Figure in the body | Gap |
|---|---|---|
| "reduces memory usage by up to 35%" | "13% - 48% memory usage reduction", fastify at 48% | Headline is lower than the measured best case |
| "reduces idle CPU usage by 5x" | Claude Code in production: p99 24% to 10%, p50 5.8% to 2.5% | The 5x figure is a hello-world app, not a real workload |
| "starts 50% faster on Linux" | "On Windows, Bun starts 2.5x faster" | The larger platform win is left out of the headline |
| "over 2,900 issues" fixed | A Bun post on 29 July said "over 3000 issues" | Two public counts, three weeks apart |
bun.lock is "lockfileVersion: 2" |
Override-using lockfiles are "lockfileVersion: 3" and unreadable by older Bun | Two lockfile versions in one release |
Day one in the issue tracker
Twenty issues were opened against oven-sh/bun on 20 August 2026. Several are explicitly labelled as regressions from 1.3.14.
| Issue | Symptom | Where it hits |
|---|---|---|
| #39766 | ws shim handleUpgrade() throws out of abortHandshake after a macrotask; the client connection never opens and nothing is logged |
WebSocket servers using the Node ws shim |
| #39764 | bun build --compile binaries are SIGKILL'd before user code runs; 1.3.14 artifacts still run on the same machine |
macOS 27 single-file executables |
| #39728 | 16 exports and 2 modules missing versus Node 24.11, while process.versions.node reports 26.3.0 |
Anything feature-detecting on the reported Node version |
| #39752 | ClientRequest drops queued body chunks, truncating chunked uploads with a valid terminator |
Streaming upload paths |
| #39747 | Piped child_process stdout has no ._handle, breaking synchronous fd-based IPC |
TypeScript 7 native sync API and similar tooling |
| #39771 | bun install skips npm:-prefixed dependencies |
Windows installs using package aliases |
Issue #39728 is the one to read carefully if your code branches on runtime capability. Bun reports Node 26.3.0 while its builtin surface is short of Node 24.11, two majors older. Any library that feature-detects by version string rather than by probing the API will take the wrong branch.
The argument about where the gains came from
The Rust port has been publicly contested since June, and the disagreement is technical rather than tribal.
Andrew Kelley, creator of the Zig programming language, published a critique on 9 July 2026 in which he wrote: "Performance increase is attributed to LTO, which Zig has supported for all of Bun's existence." Dennis Morello made the same point on 1 August: "The 2 to 5% speed gain and the roughly 20% smaller binary come from cross-language LTO, ICU trimming, and linker work that could have shipped in Zig, not from Rust as a language."
Bun's own framing supports part of that reading. The July post attributes the "2% - 5% faster" figure to cross-language link-time optimisation, and the 5x idle-CPU and 13-48% memory wins are attributed elsewhere, largely to consolidating JavaScriptCore onto mimalloc instead of running libpas and mimalloc side by side. Those are real wins. They are not obviously wins that required a language change.
There is also a factual disagreement worth flagging because it is checkable. Bun's post says the team fuzzes Bun's runtime APIs continuously with Fuzzilli. Kelley writes that during calls with the Bun team, "they were not fuzzing anything". Both statements cannot describe the same period.
On process, the record is public. Tero Piirainen counted "over 5k open pull requests" on 19 August 2026; the repository shows 4,996 open pull requests and 3,247 open issues on 20 August. Tom Lockwood, writing on 27 July, tracked robobun open PRs rising from 1,277 on 9 July to 2,475 on 27 July. And the ship date moved repeatedly: Sumner told a Hacker News thread in late July that "Most likely next Tuesday we'll do the release of 1.4." It shipped three weeks after that.
What to do this week
Do not treat 1.4 as a patch upgrade. Vercel, which shipped Bun 1.4 support for Vercel Functions on 20 August, requires you to set bunVersion to 1.4.x in vercel.json and states plainly: "Upgrading is an explicit opt-in because Bun 1.4 has several breaking changes. Review the breaking changes and update your application before upgrading." That is the right default for everyone, not only Vercel customers.
A workable sequence: pin your current version explicitly so nothing floats onto 1.4 by accident; audit for the five named breaking changes, starting with .env loading in any --bun invocation; rebuild native addons against ABI 147; run your full suite under 1.4 in CI without promoting it; and if you compile single-file binaries on macOS, test that path first because #39764 kills the process before your code runs. Teams already weighing the runtime choice should read our Bun versus Node.js backend runtime decision and the wider Deno, Bun and Node.js production comparison before treating this release as a reason to switch either way. Runtime churn is a platform decision, and it belongs in the same review as the rest of your web platform baseline.
The real cost here is not the upgrade. It is the regression window: a runtime whose entire implementation changed under a stable version number, shipping into codebases whose test suites were written against the old one.
India-specific considerations
For Indian product teams, two details matter more than the benchmarks. The glibc floor dropping to 2.17 makes Bun viable on older RHEL and CentOS 7 fleets that are still common in BFSI and government-adjacent hosting, which removes a real blocker. Against that, the day-one regressions land hardest on teams running lean on-call rotations, where a WebSocket upgrade failing without a log line costs hours rather than minutes. If your workload processes personal data, note that a runtime swap is a change to a processing system under the Digital Personal Data Protection Act 2023, so it belongs in your change record even when nothing user-facing moves.
What is still unknown
Bun has published no musl or Alpine statement in either post, so container images built on Alpine are untested territory as far as the primary sources go. There are no 1.4 patch releases yet: v1.4.0 is the only 1.4.x tag as of 20 August 2026, so there is no data on how quickly the day-one regressions get fixed. And the release post's silence on regressions means the practical answer to "is 1.4 stable" will be written in the issue tracker over the next fortnight, not in the announcement.
FAQ
How eCorpIT can help
Runtime migrations fail on the parts nobody benchmarked: native addons, environment loading, and the tests that were written against the old implementation. Our senior engineering teams run this as a controlled change, not a version bump, and eCorpIT's Node.js development services and API integration and modernisation practice cover the audit, the CI shadow run and the rollback plan. If you are weighing Bun 1.4 against staying on Node, talk to our engineering team and we will size the exposure against your actual dependency tree.
References
- Bun 1.4 release announcement, Bun, 20 August 2026.
- Rewriting Bun in Rust, Jarred Sumner, 8 July 2026.
- Bun 1.4 is now available in Vercel Functions, Vercel changelog, 20 August 2026.
- bun-v1.4.0 release tag, oven-sh/bun, GitHub.
- bun on the npm registry, npm.
- Issue #39766: ws shim handleUpgrade regression in 1.4.0, oven-sh/bun.
- Issue #30719: PathString::slice dangling reference UB, oven-sh/bun.
- My thoughts on Bun's Rust rewrite, Andrew Kelley, 9 July 2026.
- Bun 1.4 Rust rewrite worries, Tero Piirainen, 19 August 2026.
- How is the Bun rewrite in Rust going?, Tom Lockwood, 27 July 2026.
- Bun 1.4 Rust rewrite: 64 Claude agents, 535k lines of Zig, Dennis Morello, 1 August 2026.
- Hacker News discussion, item 49067854, 27 July 2026.
Last updated: 20 August 2026.
