Bun 1.4 at Scrydon: A Quiet Upgrade With Loud Early Numbers
Bun 1.4 — the first stable release after Bun's runtime was rewritten from Zig to Rust — shipped on 20 August. A day later it was running across Scrydon's staging environment. The upgrade was uneventful; the first measurements were not. Across nine Bun runtime services, average CPU fell by 49.9% and average working-set memory by 60.4%, while traced traffic rose 27.1%.
On 20 August, Bun released Bun 1.4. The next day, Bun 1.4.0 was running across Scrydon's staging environment.
The upgrade itself was reassuringly uneventful. Our builds completed, our test suites stayed green, the new images rolled out, and the services remained healthy without restarts. The first measurements were much less ordinary.
Across nine Bun runtime services.
Container working set, same nine services.
The load went up while the cost went down.
Those are early staging results, not a claim that one dependency change magically explains every movement in a distributed system. But they are encouraging enough to share, and strong enough to justify why Bun 1.4 was one of our most anticipated runtime upgrades this year.
Why Bun 1.4 Mattered to Us
Bun 1.4 is not a routine point release. It is the first stable release after Bun's runtime was rewritten from Zig to Rust. The rewrite landed in May in a pull request recording 1,009,257 additions across 2,188 files.
More importantly, the rewrite arrived with production evidence. Bun reports that Claude Code had already been running on the Rust port for months, with production CPU dropping from 24% to 10% at p99 and from 5.8% to 2.5% at p50. Prisma also launched Prisma Compute on a Bun 1.4 canary, after validating flat memory usage in a workload that had exposed a leak on the stable Bun release, and confirming that its SQL connection pool recovered correctly after scale-to-zero.
The gains are not simply a side effect of choosing Rust. Bun 1.4 consolidates JavaScriptCore and Bun on mimalloc, improves memory reclamation, reduces unnecessary garbage-collection timer work and cuts futex calls. Its published results report five times lower idle CPU, 13–48% lower memory for HTTP server applications, and roughly 50% faster start-up on Linux.
That combination — an ambitious internal rewrite, sustained production use, and improvements aimed directly at long-running server workloads — made the release particularly relevant to Scrydon.
What We Upgraded
We upgraded Bun as one runtime contract across the monorepo, not as a single version string. That included:
- the root package-manager pin and our shared GitHub Actions set-up;
- all CI, end-to-end and nightly workflow overrides;
- every Bun-backed service and test image;
- local runtime tooling and development documentation;
- digest-pinned official
oven/bun:1.4.0-alpinecontainer stages; and @types/bun1.4.0 across the workspace.
Aligning every pin matters. A runtime upgrade is difficult to trust if developers, CI and production images silently exercise different releases. Bun 1.4 also let us remove older per-suite version exceptions while retaining test-file isolation where our suites require it. The only test-level compatibility clean-up was making environment removal explicit with delete process.env.KEY, rather than assigning undefined.
After CI passed, we built the complete platform image set and deployed release candidate v1.3.24-rc.14 to staging.
What We Measured
We compared rc.14 with the preceding rc.13 rollout using equal 42-minute windows at the same pod ages — approximately 5 to 47 minutes after start-up. This avoids comparing a newly started deployment with a long-settled one. The figures below cover application containers only; Dapr and infrastructure sidecars are excluded. Memory is container working set.
rc.13 → rc.14CPU
mCPUWorking-set memory
MiB| Service | Runtime | CPU, rc.13 → rc.14 | Change | Memory, rc.13 → rc.14 | Change |
|---|---|---|---|---|---|
| Average across nine Bun runtime services | Bun | 18.7 → 9.4 mCPU | 49.9% | 754.6 → 298.5 MiB | 60.4% |
| API Platform | Bun | 58.0 → 33.4 mCPU | 42% | 1,274.2 → 513.8 MiB | 60% |
| Platform | Bun | 9.6 → 3.7 mCPU | 62% | 1,007.9 → 355.1 MiB | 65% |
| Public Docs Non-Bun control | Nginx; Bun build-time only | 0.21 → 0.20 mCPU | Flat | 5.1 → 5.1 MiB | Flat |
Public Docs uses Bun during its build but runs on Nginx, so it is shown only as a non-Bun control. That boundary prevents us from crediting Bun for unrelated changes.
Traffic makes the CPU result more interesting. Traced server-span volume across the Bun services increased by 27.1%, while aggregate CPU fell. A rough CPU-per-span proxy improved by 60.6%. The change was also broad: every Bun service in the comparison used less CPU, rather than one large service determining the entire average.
We checked production over the same period as a concurrent control. Comparable production services used 28% less CPU overall, but that movement was almost entirely API Platform. Excluding API Platform, production CPU increased by roughly 7%, while the comparable non-API-Platform Bun services in staging fell by about 54%. That does not isolate Bun as the only cause, but it makes a platform-wide external traffic dip an unlikely explanation for the staging result.
The early request data points in the same direction. Across matched routes in two API services, median latency improved by 24–33%; p95 ranged from flat to 12% better, despite both services handling more traced traffic.
What This Means for Scrydon Users
Lower runtime overhead creates more headroom for real work. If these results hold through the longer staging soak and production rollout, users should see faster common request paths and more consistent performance under load. For us, a smaller working set also means better workload density and a direct infrastructure-cost benefit: less memory reserved for runtime overhead is less memory we need to buy.
Developers may also benefit from faster local start-up. Bun reports a 50% Linux start-up improvement, but we have not yet benchmarked Scrydon's local development loop, so we are treating that as a promising upstream result — not one of our measured gains.
What Comes Next
The runtime upgrade is only the first Bun 1.4 step. We are separately evaluating bun test --parallel and bun run --parallel for shorter CI paths, bun audit fix for dependency remediation, the Rust-based React compiler integration, compile-time feature flags through bun:bundle, and ES-module bytecode for selected compiled workloads. Bun.WebView may fit targeted browser automation, although replacing Playwright requires a coverage and reliability comparison rather than a search-and-replace.
We will also benchmark Bun's parallel task runner against Turborepo on our real dependency graph and remote-cache workflow. Simpler tooling is attractive; losing correct task ordering or effective caching is not. Adoption will follow measurements.
For now, the headline is simple: Bun 1.4.0 was one of the easiest major runtime changes we have deployed, and our first staging measurements show nearly half the CPU and 60% less memory across the services that run it. We will keep measuring as the release moves through production — and report back on how much of that early promise holds at full scale.
Start the conversation
Start the conversation, schedule a call with Xavier.
Prefer to write? Email hello [at] scrydon.com and we will get back to you.