Bun v1.3.14: HTTP/3, Built-in Image API, and 7x Faster Installs

Bun v1.3.14 ships three things that have been on developers’ wishlists for a while: HTTP/3 with a single config flag, a native image processing API that eliminates the need for sharp, and a global virtual store that cuts warm install times by 7x. The release also carries a footnote worth noting — it’s the last version of Bun written in Zig. The Rust rewrite merged three days later.

HTTP/3 in One Line of Config

Getting HTTP/3 into a Node.js server means reaching for a third-party library or routing traffic through a reverse proxy. In Bun v1.3.14, you add one field to Bun.serve():

Bun.serve({
  port: 443,
  tls: { cert, key },
  http3: true,
  fetch(req) {
    return new Response("hi");
  },
});

When http3: true is set, Bun binds TCP for HTTP/1.1 and HTTP/2 alongside UDP for HTTP/3 on the same port. Existing fetch handlers work identically across all three protocols with no code changes. Bun also automatically adds an Alt-Svc header so browsers discover the QUIC endpoint without manual configuration. The Bun team reports 1.99x higher throughput over standard HTTPS in their benchmarks — though real-world numbers will vary by workload. HTTP/3 always requires TLS, and the feature is currently marked experimental. The official release post covers the full API surface, including streaming, requestIP(), and graceful shutdown across protocols.

The fetch() client also gains an experimental HTTP/3 transport. Pass { protocol: "http3" } to use QUIC directly, or rely on automatic Alt-Svc upgrades — if a server advertises HTTP/3, subsequent requests to that origin switch to QUIC automatically.

Bun.Image: No More Sharp

If you have spent any time running image processing in a JavaScript project, you have likely seen the error: Could not load the "sharp" module using the linux-x64 worker. Sharp needs platform-specific native binaries, which means CI pipelines breaking on architecture mismatches, post-install scripts failing, and friction that is disproportionate to the task of resizing a JPEG. Bun v1.3.14 ships Bun.Image, a native image API built directly into the runtime.

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

The API is chainable and covers the most common operations: resize, rotate, flip, flop, and basic color modulation. Format support includes JPEG, PNG, WebP, GIF, and BMP on all platforms, with HEIC, AVIF, and TIFF available on macOS and Windows. All sharp-compatible resize filters are present — nearest, bilinear, lanczos3, and others. The constructor accepts a file path, a buffer, or a Bun.file() reference. No npm install, no native binaries, no CI headaches. For teams already on Bun, this removes an entire dependency.

7x Faster Warm Installs

The isolated linker in bun install now supports a global virtual store. Previously, the isolated linker cloned each package into the project’s node_modules via clonefileat(), which on macOS APFS holds a volume-wide kernel lock — parallelization was effectively impossible. The fix materializes each package once into a shared <cache>/links/ directory and replaces per-project copies with symlinks. Warm installs — the most common CI path — drop from one file clone per file to one symlink per package.

To opt in, add two lines to your bunfig.toml:

[install]
linker = "isolated"
globalStore = true

The feature is experimental and disabled by default. The implementation PR has full details on the trade-offs. For CI environments, mounting ~/.bun/install/cache and the global links directory across runs gives the full benefit.

A Historical Footnote

Three days after v1.3.14 shipped, PR #30412 merged into the Bun main branch — 1,009,257 lines of Rust across 6,755 commits. Bun v1.3.14 is the last release built on the original Zig codebase. The Rust build passes 99.8% of the existing test suite and is available today via bun upgrade --canary, but it is not the default. The stated goal is memory safety rather than performance. The honest caveat: the rewrite shipped with 13,000 unsafe blocks, largely because the LLM-assisted port preserved Zig patterns rather than idiomatic Rust. That cleanup is coming. For now, v1.3.14 stable is what teams should run.

What to Do Now

Upgrade with bun upgrade. If you are running image processing, the migration from sharp to Bun.Image is straightforward — the API shape is similar enough that most pipelines port in a few lines. HTTP/3 is worth enabling in staging to benchmark against your actual workloads before touching production. And if CI install times have been a pain point, the global virtual store is worth a test with the opt-in flag. The Rust canary is interesting, but not ready for production workloads yet.