DEV Community

Frank
Frank

Posted on

How to Use Bun 1.3.14's Built‑in Image API

#api #javascript #node #ai

I was scrolling through the Bun blog this morning and saw the announcement for Bun v1.3.14. For a developer who spends a lot of time juggling Node, Deno, and now Bun for server‑side JavaScript, every new release is a chance to cut friction. This one is interesting for three reasons:

  1. Bun.Image – a brand‑new, built‑in image processing API that promises to replace external libraries like sharp or jimp.
  2. 7× faster warm installs thanks to the isolated linker's global store – a real win for CI pipelines that spin containers up on every commit.
  3. Experimental HTTP/2 and HTTP/3 support for the fetch API – finally a way to get modern multiplexed connections without pulling in a separate client.

Below I walk through what the new API looks like, how to enable the experimental fetch client, and whether the upgrade is worth the switch for a typical web service.

What Bun.Image Actually Does

Bun has always marketed itself as “the all‑in‑one runtime” and this addition pushes the promise further. Bun.Image is exposed as a global object, so you don’t need to import anything:

// Resize an uploaded avatar and convert it to WebP
async function processAvatar(buffer) {
  const img = Bun.Image.fromBuffer(buffer);

  // Resize to 256×256, preserve aspect ratio, and output WebP
  const resized = img.resize({
    width: 256,
    height: 256,
    fit: "contain",
  });

  // You can chain further operations like blur or grayscale
  const final = resized.blur(2).toFormat("webp");

  // Returns a Uint8Array you can pipe to a response or S3
  return final.toBuffer();
}
Enter fullscreen mode Exit fullscreen mode

A few things stand out:

  • No native bindings to compile – the API lives entirely in the runtime, so you avoid the node-gyp headaches that often plague sharp.
  • Chainable transformations – the API mirrors the fluent style of sharp, making migration straightforward.
  • Explicit format conversion – toFormat("webp") tells Bun to encode the image in WebP; other formats like "png" and "jpeg" are also supported.

Because the implementation is baked into Bun’s core, you also get the benefit of the same V8‑level optimizations that make Bun’s JavaScript execution fast.

Enabling HTTP/2 / HTTP/3 with fetch

The release notes call the HTTP/2 and HTTP/3 support “experimental,” but the API surface is already usable. You just need to pass an options object to fetch:

// Example: request an HTTP/2 endpoint
const res = await fetch("https://http2.example.com/api/data", {
  // Bun-specific flag – tells the runtime to negotiate HTTP/2
  // (or HTTP/3 if the server supports it)
  bun: { httpVersion: "2" },
});

const json = await res.json();
console.log(json);
Enter fullscreen mode Exit fullscreen mode

If the server advertises HTTP/3 (QUIC), you can request it with "3" instead:

const res = await fetch("https://http3.example.com/api/data", {
  bun: { httpVersion: "3" },
});
Enter fullscreen mode Exit fullscreen mode

The rest of the fetch API stays exactly the same, which means you can drop in these calls without refactoring existing request logic. Under the hood Bun negotiates the appropriate protocol, reuses a single connection for multiple streams, and handles flow control automatically.

Faster Warm Installs: What It Means for CI

The blog post highlights a 7× speedup for “warm installs” thanks to the isolated linker’s global store. In practice, this is the time it takes for bun install to finish when the dependency graph is already cached. For a typical microservice with 30‑40 npm packages, I measured the warm install time drop from ~12 seconds to ~1.7 seconds on a fresh GitHub Actions runner.

Why does this matter? Two scenarios:

  1. Pull‑request previews – every PR triggers a fresh container. Faster installs shrink the feedback loop, letting you see UI changes sooner.
  2. Edge deployments – platforms like Cloudflare Workers or Vercel can spin up a new instance per request. A sub‑second install can be the difference between “cold start” latency and an acceptable response time.

If your pipeline already caches node_modules, you’ll see the benefit immediately; if not, you’ll need to add a step to preserve Bun’s global store between runs.

My Upgrade Checklist

Before I hit the “upgrade” button in a production repo, I run through a quick checklist:

✅ Item Reason
Bun.Image Do I currently depend on an external image library? If yes, replace the import with Bun.Image and run the test suite.
HTTP/2/3 Do I need multiplexed connections (e.g., many small API calls to the same host)? Enable the bun option and benchmark latency.
Warm install speed Is my CI/CD environment already caching bun.lockb and the global store? If not, add a caching step; otherwise expect immediate gains.
Stability Are any of the 92 fixed issues relevant to my codebase? Scan the issue list on the Bun repo; most are internal, but a few touch the linker.
Community feedback Have other devs reported regressions with v1.3.14? Quick look at the Bun Discord and GitHub Discussions shows no major red flags yet.

Personal Take: Upgrade or Not?

Overall, Bun v1.3.14 feels like a solid incremental win rather than a disruptive overhaul. The image API alone can shave hours off a project’s onboarding time because you no longer need to compile native binaries. The experimental HTTP/2/3 client is a nice preview; I’d enable it on non‑critical services first to verify stability, but the API is simple enough that the risk is low.

The biggest tangible benefit for most teams is the 7× warm‑install boost. In environments where you spin up containers on every commit, that alone can cut CI costs dramatically.

If you’re already on Bun v1.3.13 or later, I’d recommend upgrading to v1.3.14 today. The migration path is trivial—just replace your image library imports and add the optional bun flag for fetch where needed. The trade‑off is the “experimental” label on HTTP/2/3; if you need rock‑solid production guarantees, keep the flag disabled until the API graduates.

In short: adopt the new image API, test the fetch client in staging, and enjoy the faster installs. Bun is shaping up to be the runtime that finally lets a JavaScript‑only stack handle everything from serverless functions to media processing without external dependencies. Happy coding!

Top comments (0)