By Bun v1.3.14, released May 13, crossed a line that deserves more than a changelog skim. Three features landed simultaneously: a built-in image processing API, experimental HTTP/3 server support, and a global package store that makes warm installs seven times faster. Taken together, they push Bun noticeably closer to a self-sufficient backend platform — and quietly erode the most common reasons developers give for staying on Node.js.
Bun.Image: The End of the Sharp Install Nightmare
Sharp is excellent software. The problem was never Sharp’s quality — it was the install experience. Native bindings, platform-specific prebuilds, Alpine vs glibc incompatibilities, and the CI pipeline failures that arrived every time a new developer cloned the repo on a different architecture. If you’ve shipped a Node.js image service, you’ve felt this.
Bun v1.3.14 adds Bun.Image, a built-in image processing API with no native dependencies. It handles JPEG, PNG, WebP, GIF, and BMP natively, with HEIC, AVIF, and TIFF supported on macOS and Windows via OS backends. The API is a chainable pipeline:
await Bun.file("photo.jpg")
.image()
.resize(800, 600, { fit: "inside" })
.webp({ quality: 85 })
.write("thumb.webp");Or inline inside an HTTP handler in a single expression:
return new Response(new Bun.Image(upload).resize(200).jpeg());The performance numbers against Sharp 0.34.5 are legitimately impressive: metadata() runs 70 times faster (0.004ms vs 0.28ms), and resize operations run 1.27–1.38 times faster. The more important number, though, is zero — as in zero native dependencies, zero platform-specific prebuilds, zero npm rebuild sharp in your Dockerfile.
Input accepts path strings, ArrayBuffer/TypedArray with zero-copy, Blob, BunFile, S3File, and data: URLs. Outputs cover every format you’d need: .jpeg(), .webp(), .png(), plus .placeholder() which generates a thumbhash data URL for blur-up loading. Full API details are in the Bun.Image documentation. If Bun.Image removes the last reason your team was staying on Node for a particular service, that was probably the intended effect.
HTTP/3: Bun Ships It First, With the Right Caveats
Experimental HTTP/3 support, powered by lsquic v4.6.2, is now available in both Bun.serve() and fetch(). Enabling it requires TLS — HTTP/3 mandates it — and a single flag:
Bun.serve({
port: 443,
tls: { cert, key },
http3: true,
fetch(req) {
return new Response("Hello HTTP/3");
}
});The benchmark numbers are striking: 509,135 requests per second on a static route versus 189,130 for HTTPS/1.1 — a 2.7x gap on the same hardware. Dynamic handlers show a similar 2x improvement. These are loopback benchmarks on a single process. Real production numbers will differ significantly, and Bun’s own documentation flags this as highly experimental. No WebSocket support over HTTP/3 yet, no 0-RTT, no trailers.
Take the production caveat seriously. But also recognize what’s happening: Bun is among the first JavaScript runtimes to ship HTTP/3 server support at all. QUIC’s advantages — no TCP head-of-line blocking, faster connection setup on high-latency networks, better resilience to packet loss — are real. Getting exposure to the API now, in development, is worth doing. Enable it in staging, run your own benchmarks, and watch it mature toward production-readiness.
Global Virtual Store: Seven Times Faster Warm Installs
If you work in a monorepo, or if CI pipeline time compounds into hours per week, this is the feature that will directly affect your day. The isolated linker’s global virtual store turns warm installs from file copies into symlinks.
The old approach: for each install, clone package files from the cache into the project’s node_modules. On macOS APFS, clonefileat() holds a volume-wide kernel lock — parallelization cannot help. The new approach: materialize each package once into a global cache directory, then symlink from node_modules. One symlink per package instead of one file copy per file.
The result on Apple Silicon macOS: 841ms down to 115ms. System time drops from 1,256ms to 94ms. The clonefileat call count goes from 1,387 to zero. Enable it with one line in bunfig.toml:
[install]
globalStore = truePackages with patches, those in trustedDependencies, and workspace/file/link dependencies still use the per-project store as a fallback. See the global store documentation for the full eligibility rules. Everything else gets the global store treatment, and node_modules goes from hundreds of megabytes per project to a few megabytes of symlinks.
Smaller Binaries, Faster Internals
Cross-language link-time optimization across Zig and C++ landed in this release. The Linux x64 binary is 8.58MB smaller; Windows x64 is 17.66MB smaller. The more interesting side effects: 6.5% faster escapeHTML, 3.5% faster HTTP throughput — because LLVM can now inline and optimize across language boundaries in the same compilation pass. The runtime gets leaner and faster from the same change. This is the kind of engineering that does not generate headlines but compounds over time.
Where Things Stand
Worth noting: Node.js 26 shipped May 5 with the Temporal API finally stable. Node is not standing still. For existing applications with years of ecosystem investment, switching runtime is not a default recommendation in 2026.
What v1.3.14 does represent is Bun’s continued accumulation of built-ins: S3, SQL, SQLite, test runner, bundler, and now image processing. The pattern is clear — Bun is building a runtime where fewer npm packages are necessary because more capabilities are just there. Whether that ends up being a distribution advantage or a maintenance liability long-term is still an open question. Right now, it’s removing real friction for developers who hit those specific pain points.
For greenfield projects, CLIs, image processing APIs, or anything where CI install speed compounds daily: update and test. The full release notes are available on the Bun blog.
bun upgrade
