by Martin Listiak

Share article

On 20 August 2026, Bun shipped version 1.4. On paper it is a minor version bump. In practice it is the most significant release since 1.0: the entire runtime has been rewritten from Zig to Rust, and the team used the rewrite to close a large share of the remaining gap with Node.js.

We have been watching Bun closely since its first stable release. It has always been fast, but for most of our client work the deciding question was never speed. It was whether we could trust it in production, next to the frameworks, SDKs and observability tooling our partners already depend on. Bun 1.4 is the first release where the honest answer to that question starts to look like yes.

A rewrite you are not supposed to notice

Rewriting a runtime in a different language is usually the kind of project that stalls a product for a year. What stands out about Bun 1.4 is that the rewrite is almost invisible from the outside. The APIs are the same, the CLI is the same, and existing projects are expected to keep working after a simple bun upgrade.

The rewrite was not done in isolation either. According to the Bun team, Claude Code had already been running on the Rust port for months before the release, and Prisma launched Prisma Compute on it. That matters more to us than any benchmark: it means the new codebase has been carrying real production traffic, not just passing a test suite.

The headline numbers are still worth stating:

• +1,517 newly passing tests from the Node.js test suite, the largest compatibility jump since 1.0
• 2,900+ issues fixed
• 5x lower idle CPU usage
• Up to 35% less memory
• ~50% faster startup on Linux

Node.js compatibility is no longer the asterisk

For years, adopting Bun came with a caveat: it works, unless one of your dependencies touches a corner of Node that Bun has not implemented yet. That caveat is shrinking fast. Core modules such as node:http, node:fs, node:stream, node:zlib and node:vm now pass around 97% of Node’s own tests, and node:events, node:sqlite and node:trace_events pass all of them.

More importantly, the packages teams actually depend on now work: Playwright, Next.js 16 builds, vitest with coverage, OpenTelemetry, dd-trace, Nuxt, testcontainers, grpc-js, the AWS S3 SDK and TypeORM, among others. Observability in particular has been a blocker for us in the past. A runtime you cannot trace is a runtime you cannot run for a client.

Performance where it actually costs money

Raw request throughput has never been Bun’s problem. What 1.4 improves is the less glamorous side of performance: idle CPU and memory. Those are the numbers that end up on a cloud bill.

The Bun team shared peak memory figures for serving one million requests with common frameworks:

Startup has improved just as much. A hello-world script now starts in about 5 ms on Linux, compared with 10.9 ms on Bun 1.3 and 27.2 ms on Node 26. For serverless functions, CLIs and short-lived workers, that difference is felt on every single invocation.

In Claude Code’s production fleet, p99 CPU usage fell from 24% to 10%. That is the kind of result that changes how many containers you need, not just how a benchmark chart looks.

More of the toolchain, built in

Bun has always tried to replace a stack of separate tools with a single binary. Version 1.4 pushes that idea further with a set of new built-in APIs:

• Bun.Image decodes, resizes and encodes JPEG, PNG, WebP, GIF and BMP without sharp or native add-ons
• Bun.WebView provides headless browser automation using the system WebKit or an installed Chrome
• Bun.markdown renders Markdown to HTML or React, with GitHub-flavoured extensions
• Bun.cron() registers real OS-level scheduled jobs
• Bun.Terminal adds a built-in PTY for spawning interactive processes

Each of these replaces a dependency that would otherwise need to be installed, audited and kept up to date. For small, focused services, fewer dependencies means a smaller attack surface and less maintenance over the lifetime of a project.

A better day-to-day for engineering teams

Some of the most useful changes are in the tooling teams use every day. The test runner now supports --parallel, --shard, --changed and --retry, plus Jest-style fake timers. That closes most of the gap that kept larger projects on Jest or vitest.

The package manager gained bun audit fix, bun dedupe, bun prune and bun pm licenses. On a T3-stack Next.js app, a first install took 1.41 seconds compared with 18.1 seconds for npm. The bundler can now run React Compiler natively: on around 860 components it added 71 ms of build time, against 9.15 seconds for the Babel plugin.

HTTP/3 support in Bun.serve() and HTTP/2 and HTTP/3 in fetch() are available too, though both are still experimental.

What to check before you upgrade

A rewrite of this size will have rough edges, and a few defaults have changed. Before moving production traffic, it is worth checking:

• TLS verification is stricter, so services with self-signed or misconfigured certificates may start failing
• Bun.YAML now follows YAML 1.2, which changes how some values are parsed
• Bun invoked as node no longer auto-loads .env files
• trustedDependencies defaults now apply only to npm registry packages, so git, file and link dependencies with install scripts need to be listed explicitly
• Sourcemaps are no longer served for HTML routes in production by Bun.serve

Our recommendation is simple: pin the exact Bun version in CI and Dockerfiles, upgrade on a branch, run your full test suite and watch the first patch releases before rolling out widely. The early patches in the 1.4 line have already fixed a number of regressions.

Our take

Bun 1.4 is not interesting because it is written in Rust. It is interesting because the move to Rust came with broad compatibility, lower resource usage and real production validation at the same time. For new services, internal tools, CLIs and serverless workloads, we now consider Bun a serious default rather than an experiment.

For large existing Node.js systems, the case is stronger than ever, but the decision should still be driven by evidence: measure memory, cold starts and CI times on your own workload. If the numbers hold up, the savings compound across every environment you run.

The question used to be whether Bun was ready for production. With 1.4, the question is whether your workload is ready to benefit from it.

Martin Listiak, CTO, Format-3

By Martin Listiak

CTO

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms