--- title: Bun v1.3.14 description: "Fixes 92 issues (addressing 380 πŸ‘). Bun.Image β€” a built-in image processing API, 7x faster warm installs with the isolated linker's global store, experimental HTTP/2 and HTTP/3 clients for fetch(), HTTP/3 (QUIC) in Bun.serve(), rewritten fs.watch() on Linux and macOS, --no-orphans CLI flag, process.execve(), Bun.Terminal on Windows via ConPTY, FreeBSD and Android builds, shared SSL_CTX cache, smaller binaries, and many bugfixes and Node.js compatibility improvements." date: "2026-05-13T03:19:35.943Z" author: jarred --- #### To install Bun {% codetabs %} ```sh#curl $ curl -fsSL https://bun.sh/install | bash ``` ```sh#npm $ npm install -g bun ``` ```sh#powershell $ powershell -c "irm bun.sh/install.ps1|iex" ``` ```sh#scoop $ scoop install bun ``` ```sh#brew $ brew tap oven-sh/bun $ brew install bun ``` ```sh#docker $ docker pull oven/bun $ docker run --rm --init --ulimit memlock=-1:-1 oven/bun ``` {% /codetabs %} #### To upgrade Bun ```sh $ bun upgrade ``` ## `Bun.Image` β€” Built-in Image Processing Bun now ships a built-in image processing API that handles JPEG, PNG, WebP, GIF, and BMP β€” plus HEIC, AVIF, and TIFF on macOS and Windows β€” with **zero native module installs**. `Bun.Image` provides a chainable pipeline for decoding, transforming, and encoding images, designed as a drop-in alternative to sharp for common server-side image operations. ```js // Resize and convert a photo to WebP await Bun.file("photo.jpg") .image() .resize(1024, 1024, { fit: "inside" }) .rotate(90) .webp({ quality: 85 }) .write("thumb.webp"); // Generate a thumbnail from an upload in a single expression return new Response(new Bun.Image(upload).resize(200).jpeg()); ``` ### Input sources `Bun.Image` accepts path strings, `ArrayBuffer`/`TypedArray` (zero-copy), `Blob`/`BunFile`/`S3File`, and `data:` URLs. You can also use `Bun.file("photo.jpg").image()` or `blob.image()` to start a pipeline. ### Chainable transforms The pipeline supports `.resize(w, h?, {filter, fit, withoutEnlargement})`, `.rotate(90|180|270)`, `.flip()`, `.flop()`, and `.modulate({brightness, saturation})`. Output format is set with `.jpeg()`, `.png()`, `.webp()`, `.heic()`, or `.avif()` β€” each with format-specific quality/compression options. ### Resize filters All sharp filters are supported: `nearest`, `box`, `bilinear`, `cubic`, `mitchell`, `lanczos2`, `lanczos3`, plus `mks2013` and `mks2021`. ### Terminal methods All processing runs off the main thread (except `metadata()`). Output via `.bytes()`, `.buffer()`, `.blob()`, `.toBase64()`, `.dataurl()`, `.placeholder()` (thumbhash), `.metadata()`, or `.write(dest)`. ```js const meta = await new Bun.Image(buf).metadata(); // { width: 1920, height: 1080, format: "jpeg", ... } const placeholder = await Bun.file("hero.jpg").image().placeholder(); // thumbhash data URL for blur-up ``` ### Body integration `Bun.Image` instances work directly as response/request bodies with automatic `Content-Type`: ```js return new Response(new Bun.Image(upload).resize(200).jpeg()); ``` ### Platform-specific formats | Format | macOS | Windows | Linux | | ------------ | ------------------------------------- | ------------------ | ----- | | JPEG | βœ… | βœ… | βœ… | | PNG | βœ… | βœ… | βœ… | | WebP | βœ… | βœ… | βœ… | | GIF | βœ… | βœ… | βœ… | | BMP (simple) | βœ… | βœ… | βœ… | | TIFF | βœ… decode | βœ… decode | β€” | | HEIC | βœ… decode + encode | βœ… decode + encode | β€” | | AVIF | βœ… decode (+ encode on Apple Silicon) | βœ… decode + encode | β€” | JPEG, PNG, WebP, GIF, and BMP use statically linked codecs and produce identical output across all platforms. HEIC, AVIF, and TIFF use OS system backends (ImageIO + vImage on macOS, WIC on Windows) with lazy symbol resolution for zero startup cost. ### Performance vs sharp 0.34.5 Benchmarked on linux/x64 with 50 iterations and `sharp.concurrency(1)`: | Operation | Bun.Image | sharp | Speedup | | --------------------------- | --------: | -------: | --------: | | `metadata()` | 0.004 ms | 0.28 ms | **70Γ—** | | 1080p PNG β†’ 400Γ—400 β†’ JPEG | 28.6 ms | 39.5 ms | **1.38Γ—** | | 1080p PNG β†’ 800Γ—600 β†’ WebP | 82.7 ms | 110.1 ms | **1.33Γ—** | | 4K JPEG β†’ 800Γ—450 β†’ JPEG | 35.8 ms | 45.5 ms | **1.27Γ—** | | 4K JPEG β†’ 1920Γ—1080 β†’ JPEG | 57.2 ms | 69.9 ms | **1.22Γ—** | | 12MP JPEG β†’ 1024Γ—768 β†’ WebP | 138 ms | 165 ms | **1.20Γ—** | The performance comes from i16 fixed-point SIMD resize kernels, JPEG IDCT scaling to the smallest sufficient size, zero-copy ArrayBuffer borrowing, and a single pre-allocated arena for resize scratch memory. ## Global Virtual Store `bun install --linker=isolated` now supports a shared global virtual store via the `install.globalStore = true` option in `bunfig.toml`. Instead of cloning every package from the cache into each project's `node_modules` on every install, packages are materialized **once** into a global `/links/` directory, and each project's `node_modules/.bun/@` becomes a symlink into it. Warm installs β€” lockfile present, cache warm, `node_modules` wiped (the common CI path) β€” now perform ~1 `symlink()` per package instead of ~1 `clonefileat()` per file copy. On macOS APFS, `clonefileat()` holds a volume-wide kernel lock that made parallelization ineffective. The global store eliminates those calls entirely on the warm path. **Benchmarks** β€” warm install of a ~1,400-package fixture on Apple Silicon macOS (`hyperfine --warmup 3 --runs 10`): | | Wall time | System time | `clonefileat` calls | | ------------------------------- | ---------- | ----------- | ------------------- | | `--linker hoisted` | 823 ms | 478 ms | 1,387 | | `--linker isolated` (before) | 841 ms | 1,256 ms | 1,387 | | **`--linker isolated` (after)** | **115 ms** | **94 ms** | **0** | This is still experimental, so the global store is **off by default** with the isolated linker. To enable: ```toml # bunfig.toml [install] globalStore = true ``` Or via environment variable: ```bash BUN_INSTALL_GLOBAL_STORE=1 bun install ``` A package is eligible for the global store only when it comes from an immutable cache source (npm registry, git, tarball β€” unpatched, no trusted lifecycle scripts) and all of its transitive dependencies are also eligible. Ineligible packages fall back to per-project copies automatically. The entry hash encodes the package's resolved dependency closure, so two projects that resolve a package to the same transitive versions share one on-disk entry, while a project with different resolutions gets its own. This release also fixes a pre-existing issue: Bun now synthesizes an implicit `"*"` optional peer dependency for entries that appear in `peerDependenciesMeta` but not in `peerDependencies` (matching pnpm/yarn behavior). This fixes compatibility with packages like `webpack-cli`. ## HTTP/3 (QUIC) support in `Bun.serve` > ⚠️ **Highly experimental.** HTTP/3 support is new and likely has bugs. Do not deploy `http3: true` to production yet. `Bun.serve` now supports HTTP/3 over QUIC. Enable it with a single flag: ```ts Bun.serve({ port: 443, tls: { cert, key }, http3: true, // also listen on UDP/443 for HTTP/3 fetch(req) { return new Response("hi"); }, }); ``` When `http3: true` is set alongside `tls`, Bun binds **TCP** for HTTP/1.1+2 and **UDP** for HTTP/3 on the same port. Your existing `fetch` handler and `routes` work identically across all three protocols β€” no code changes needed. HTTP/1.1 and HTTP/2 responses automatically include `Alt-Svc: h3=":"; ma=86400` so browsers discover the QUIC endpoint. You can also serve HTTP/3 only: ```ts Bun.serve({ port: 443, tls: { cert, key }, http3: true, http1: false, // disable HTTP/1.1 fetch(req) { return new Response("h3 only"); }, }); ``` Everything you'd expect works over HTTP/3: `new Response(readableStream)` for streaming, `new Response(Bun.file("large.bin"))`, `new Response(req.body)` passthrough, `req.url`/`req.headers`/`req.method` across `await` boundaries, `requestIP()`, `server.reload()`, and graceful `server.stop()`. ### Performance On Linux x64 (single process, loopback), HTTP/3 is significantly faster than HTTPS/1.1 from the same server instance: | Benchmark | HTTP/3 | HTTPS/1.1 | HTTP/1.1 | | ----------------------- | ----------------: | ------------: | ------------: | | Static route (`routes`) | **509,135 req/s** | 189,130 req/s | 239,476 req/s | | Dynamic `fetch` handler | **283,485 req/s** | 142,323 req/s | 171,696 req/s | ~50% of HTTP/3 CPU time is inside lsquic; further optimizations may come in a future releas.e ### Limitations - **WebSocket over HTTP/3** is not supported yet (`server.upgrade()` returns `false`). WebTransport is a separate project. - **0-RTT** is disabled. - `unix:` socket addresses skip the H3 listener (QUIC over Unix sockets is non-standard). - No trailer support, no `Expect: 100-continue` (matching HTTP/1.1 behavior). Powered by [lsquic](https://github.com/litespeedtech/lsquic) v4.6.2. ## Experimental HTTP/2 Client for `fetch()` `fetch()` now supports HTTP/2 as an experimental feature. When enabled, Bun negotiates `h2` via TLS ALPN β€” multiple concurrent fetches to the same origin share a single multiplexed TCP+TLS connection instead of opening separate HTTP/1.1 connections. Enable it globally with an environment variable or CLI flag, or opt in per-request: ```js // Opt in globally: // BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP2_CLIENT=1 bun run app.js // bun run --experimental-http2-fetch app.js // Or per-request (works without the env flag): const res = await fetch("https://example.com", { protocol: "http2" }); ``` ### Multiplexing & connection coalescing Parallel fetches to the same origin share one TLS handshake and one connection. The first request opens the socket; subsequent requests attach to the same HTTP/2 session up to the server's `MAX_CONCURRENT_STREAMS` limit, with overflow queued automatically. ### Per-request protocol control The new `protocol` option in `RequestInit` lets you pin the HTTP version: ```js // Force HTTP/2 β€” fails with HTTP2Unsupported if the server doesn't support it await fetch("https://example.com", { protocol: "http2" }); // Force HTTP/1.1 β€” ignores the experimental flag await fetch("https://example.com", { protocol: "http1.1" }); ``` Accepted values: `"http2"`, `"h2"`, `"http1.1"`, `"h1"`. ### What works - **Keep-alive pooling** β€” idle HTTP/2 sessions (with HPACK state) are reused by subsequent requests - **Streaming request bodies** β€” `ReadableStream` bodies are sent as DATA frames with proper flow control - **`REFUSED_STREAM` and graceful `GOAWAY`** β€” transparently retried (up to 5 attempts) for replayable bodies - **Content-Length enforcement** per RFC 9113 Β§8.1.1 - **`Expect: 100-continue`** support ### Hardening The HTTP/2 client also includes RFC 9113 conformance and denial-of-service protections: - **CONTINUATION flood / HPACK bomb mitigation**: 256 KiB cap on both header-block accumulation and decoded header lists, advertised via `SETTINGS_MAX_HEADER_LIST_SIZE`. - **PING reflection attack mitigation**: 1 MiB cap on queued PING/SETTINGS-ACK control frames prevents unbounded memory growth from malicious servers. - The first server frame must be SETTINGS per RFC 9113 β€” connections that violate this are immediately terminated. - `RST_STREAM(NO_ERROR)` mid-body now correctly fails the request instead of silently truncating the response. - `REFUSED_STREAM` retries only when no data has been delivered to the caller. - Content-Length mismatches with actual DATA frame bytes are now detected and rejected. - Trailers without `END_STREAM` are now rejected per spec. - `GOAWAY` no longer drops already-completed streams. ### Not yet supported HTTP proxies/CONNECT tunneling, Unix sockets, server push, and cleartext HTTP/2 (h2c) are not yet supported. The HTTP/1.1 path is completely unchanged when the flag is off and `protocol` is not set. ## Experimental HTTP/3 Client for `fetch()` `fetch()` now supports an experimental HTTP/3 client using the `protocol` option. This uses an lsquic-backed QUIC transport that runs alongside the existing HTTP/1.1 and HTTP/2 paths. > ⚠️ **Highly experimental.** This is an early preview β€” the API may change in future releases. ```js const res = await fetch("https://example.com/", { protocol: "http3" }); console.log(await res.text()); ``` Both `"http3"` and `"h3"` are accepted as protocol values. The HTTP/3 client shares the same redirect, decompression, and response handling pipeline as HTTP/1.1 and HTTP/2, so existing `fetch()` behavior is preserved. **What's supported:** - All standard HTTP methods (GET, POST, PUT, DELETE, HEAD) - Request and response headers, JSON bodies, gzip compression - Redirects - Large request/response bodies (1 MB+ round-trips) - Concurrent multiplexed requests over a single QUIC connection - Connection pooling and sequential reuse - `ReadableStream` request body uploads - Full-duplex bidirectional streaming (server can respond while upload is still in progress) - `rejectUnauthorized` TLS option (defaults to `true`) - `AbortSignal` support ### Alt-Svc HTTP/3 upgrades The HTTP/3 client can also automatically upgrade `fetch()` requests to HTTP/3 via the `Alt-Svc` header (RFC 7838). When a server advertises `Alt-Svc: h3` in an HTTPS response, subsequent requests to that origin are routed over QUIC instead of TCP. This is opt-in while the HTTP/3 client matures. Enable it with the CLI flag or environment variable: ```sh # CLI flag bun --experimental-http3-fetch app.ts # Environment variable BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP3_CLIENT=1 bun app.ts ``` ```js // First request goes over TCP/TLS as usual const res1 = await fetch("https://example.com/api"); // If the response includes `Alt-Svc: h3=":443"`, // the next request to the same origin uses QUIC/HTTP-3 const res2 = await fetch("https://example.com/api"); ``` The upgrade is transparent and per-origin β€” cross-origin redirects re-evaluate from HTTP/1.1, and requests that aren't eligible (proxied, unix socket, `sendfile`, or pinned to a specific protocol) gracefully fall back to TCP. ## Rewritten `fs.watch()` backend on Linux, macOS, and FreeBSD Bun's `fs.watch()` implementation on POSIX platforms has been completely rewritten to talk directly to the OS file-watching APIs (inotify, FSEvents, kqueue) instead of routing through Bun's internal bundler watcher. This fixes several long-standing bugs and reduces complexity significantly. ### Recursive watching now tracks new directories (Linux) Previously, `fs.watch("dir", { recursive: true })` only registered the directory tree that existed at the time `watch()` was called. Directories created _after_ the watch started were never tracked, so files inside them were invisible to the watcher. ```js import fs from "node:fs"; // Now correctly detects changes inside directories created after watch() starts fs.watch("./src", { recursive: true }, (event, filename) => { console.log(event, filename); }); // mkdir src/newDir && touch src/newDir/file.txt // Previously: only "rename newDir" β€” file.txt was missed // Now: "rename newDir", "rename newDir/file.txt", "change newDir/file.txt" ``` ### Deleted-and-recreated files emit `change` events again (Linux) When a watched file was deleted and recreated, subsequent modifications to the recreated file would silently stop emitting `change` events. This is now fixed β€” the new inotify watch descriptor is correctly registered on recreation. ### macOS no longer spins up two watcher threads Previously, `fs.watch()` on a directory on macOS would start _both_ a kqueue watcher (via the bundler watcher) and an FSEvents `CFRunLoop` thread. The new implementation uses FSEvents exclusively for both files and directories, matching libuv's behavior and halving the thread overhead. ## `--no-orphans` β€” exit when the parent process dies Bun now supports an opt-in mode that automatically exits when its parent process dies β€” even if the parent was `SIGKILL`ed and never had a chance to forward a signal. On exit, Bun also recursively `SIGKILL`s every descendant process it spawned. This is useful when Bun is launched by a supervisor (Electron, a CI runner, a thin shim) that may be force-killed. Without this option, Bun would be silently reparented to `launchd`/`init` and keep running forever, along with anything it spawned. There are three equivalent ways to enable it: ```sh # CLI flag (new) bun --no-orphans run my-script # bunfig.toml [run] noOrphans = true # Environment variable BUN_FEATURE_FLAG_NO_ORPHANS=1 bun run my-script ``` The flag is automatically inherited by nested Bun processes, so enabling it once at the top level is sufficient. **How it works:** - **Linux**: Uses `prctl(PR_SET_PDEATHSIG, SIGKILL)` β€” kernel-delivered, no polling, no thread. Children spawned from the main thread also inherit `PDEATHSIG` by default so non-Bun descendants are covered. - **macOS**: Registers a `EVFILT_PROC`/`NOTE_EXIT` watch for the original parent pid on the existing event loop's kqueue β€” the same mechanism Bun already uses to watch child process exits. No dedicated thread, no extra file descriptor. On clean exit, Bun walks its process tree and uses a **stop-verify-kill** strategy for pid-reuse safety: each descendant is `SIGSTOP`ped, its ppid is re-verified, and only then is it `SIGKILL`ed. This prevents accidentally killing an unrelated process that recycled a stale pid. **macOS coverage is now comprehensive.** Previously, `bun run