Bun v1.3.12 | Bun Blog

curl -fsSL https://bun.sh/install | bash

npm install -g bun

powershell -c "irm bun.sh/install.ps1|iex"

scoop install bun

brew tap oven-sh/bun

brew install bun

docker pull oven/bun

docker run --rm --init --ulimit memlock=-1:-1 oven/bun

bun upgrade

Bun now ships with native headless browser automation built into the runtime. Two backends, one API:

In the next version of Bun

Bun.WebView programmatically controls a headless web browser in Bun pic.twitter.com/Yp8UiNoeoy

All input is dispatched as OS-level events — sites can't distinguish view.click() from a real mouse click (isTrusted: true). Selector-based methods auto-wait for actionability, Playwright-style: the element must be attached, visible, stable, and unobscured before the action fires.

await using view = new Bun.WebView({ width: 800, height: 600 });
await view.navigate("https://bun.sh");

await view.click("a[href="http://bun.zhutiblog.com/com/'/docs']"); // waits for actionability, native click
await view.scroll(0, 400); // native wheel event, isTrusted: true
await view.scrollTo("#install"); // scrolls every ancestor, waits for visible

const title = await view.evaluate("document.title");
const png = await view.screenshot({ format: "jpeg", quality: 90 });
await Bun.write("page.jpg", png);

All methods work across both backends:

Bun.WebView extends EventTarget — on the Chrome backend, CDP events are dispatched as MessageEvents with the params on event.data. Constructor options include backend ("webkit", "chrome", or { type: "chrome", path, argv }), console to capture page logs, and dataStore for persistent profiles. One browser subprocess is shared per Bun process; additional new Bun.WebView() calls open tabs in the same instance.

You can now render Markdown files directly in your terminal. When you run bun ./file.md, Bun reads the file, renders it as beautifully formatted ANSI output, and prints it to stdout with no JavaScript VM startup overhead.

In the next version of Bun

bun ./hello.md & Bun.markdown.ansi(string) pretty-prints markdown to terminal-friendly ansi text pic.twitter.com/yp7jYKZL8k

You can also use the new Bun.markdown.ansi() API programmatically:

// Render markdown to an ANSI-colored string
const out = Bun.markdown.ansi("# Hello\n\n**bold** and *italic*\n");
process.stdout.write(out);

// Plain text mode — no escape codes
const plain = Bun.markdown.ansi("# Hello", { colors: false });

// Enable clickable hyperlinks
const linked = Bun.markdown.ansi("[docs](https://bun.sh)", {
hyperlinks: true,
});

// Custom line width for wrapping
const wrapped = Bun.markdown.ansi(longText, { columns: 60 });

// Inline images via Kitty Graphics Protocol (Kitty, WezTerm, Ghostty)
const withImg = Bun.markdown.ansi("![alt](./logo.png)", {
kittyGraphics: true,
});

In the next version of Bun

Async stacktraces are supported on native APIs like node:fs, Bun.write, node:http, node:dns & more.

This makes debugging easier pic.twitter.com/PHospWtxtg

Bun.cron now supports an in-process callback overload that runs a function on a cron schedule. This is ideal for long-running servers and containers where you want scheduled work that shares state with the rest of your application.

In the next version of Bun

Bun.cron() accepts a callback for recurring in-process tasks pic.twitter.com/HQ3s3rxGEO

This complements the existing OS-level Bun.cron(path, schedule, title) which registers persistent crontab/launchd/Task Scheduler entries. The in-process variant is lighter, works identically across platforms, and lets your handler access database pools, caches, and module-level state directly.

Key behaviors:

// Error handling example
process.on("unhandledRejection", (err) => console.error("cron failed:", err));

Bun.cron("* * * * *", async () => {
await mightThrow(); // logged, then retried next minute
});

Thanks to @alii for the contribution!

Two improvements to Bun.udpSocket() that bring it closer to libuv/Node.js behavior:

ICMP errors no longer silently close the socket. On Linux, sending a UDP packet to an unreachable port previously caused the socket to silently close, breaking all other sends on the same socket. Now, ICMP errors (port unreachable, host unreachable, TTL exceeded, etc.) are surfaced through the error handler, and the socket stays open:

const sock = await Bun.udpSocket({
socket: {
error(err) {
console.log(err.code); // 'ECONNREFUSED'
},
},
});
sock.send("ping", 1, "127.0.0.1"); // dead port — error handler fires, socket stays open

Truncated datagrams are now detectable. When a received datagram is larger than the receive buffer, the kernel silently truncates it. The data callback now receives a fifth flags argument so you can tell truncated payloads from complete ones:

const sock = await Bun.udpSocket({
socket: {
data(socket, data, port, address, flags) {
if (flags.truncated) {
console.log("Datagram was truncated!");
}
},
},
});

Bun's unix domain socket behavior was inverted from Node.js/libuv in two important ways:

This meant Bun could silently steal a live socket from another process on listen(), and leaked .sock files on stop()/close().

Now Bun matches Node.js semantics: binding to an existing socket file correctly returns EADDRINUSE, and closing a listener automatically cleans up the socket file. This applies to Bun.listen, Bun.serve, and net.Server with unix sockets.

import { existsSync } from "node:fs";

const listener = Bun.listen({
unix: "/tmp/my.sock",
socket: { data() {}, open() {} },
});

existsSync("/tmp/my.sock"); // true

listener.stop();

existsSync("/tmp/my.sock"); // false — automatically cleaned up

// Binding to an existing socket now correctly throws EADDRINUSE
// instead of silently taking over the socket
import { listen } from "bun";

const a = listen({ unix: "/tmp/my.sock", socket: { data() {}, open() {} } });

try {
// Previously: silently unlinked and stole the socket
// Now: throws EADDRINUSE, matching Node.js behavior
const b = listen({ unix: "/tmp/my.sock", socket: { data() {}, open() {} } });
} catch (e) {
console.log(e.code); // "EADDRINUSE"
} finally {
a.stop();
}

Bun's underlying JavaScript engine (WebKit's JavaScriptCore) has been upgraded with over 1,650 upstream commits, bringing significant performance improvements, new language features, and bug fixes.

The using and await using declarations from the TC39 Explicit Resource Management proposal are now supported natively in JavaScriptCore:

function readFile(path) {
using file = openFile(path); // file[Symbol.dispose]() called automatically at end of block
return file.read();
}

async function fetchData(url) {
await using connection = await connect(url); // connection[Symbol.asyncDispose]() awaited at end of block
return connection.getData();
}

Thanks to @sosukesuzuki for the contribution!

Standalone executables created with bun build --compile on Linux now use a proper ELF section (.bun) to embed the module graph, matching the existing approach on macOS and Windows. Previously, the embedded data was read from /proc/self/exe at startup, which failed when the binary had execute-only permissions (chmod 111).

With this change, the kernel maps the data via PT_LOAD during execve — meaning zero file I/O at startup and no read permission required on the binary.

bun build --compile app.ts --outfile myapp

chmod 111 myapp

./myapp # works now on Linux

Thanks to @dylan-conway for the contribution!

URLPattern.test() and URLPattern.exec() are now significantly faster. The internal regex matching now calls the compiled regex engine directly instead of allocating temporary JavaScript objects for each URL component, eliminating up to 24 GC allocations per call.

const pattern = new URLPattern({ pathname: "/api/users/:id/posts/:postId" });

// 2.16x faster
pattern.test("https://example.com/api/users/42/posts/123");

// 1.43x faster
pattern.exec("https://example.com/api/users/42/posts/123");

As a side effect, URLPattern internals no longer pollute RegExp.lastMatch / RegExp.$N — previously, calling pattern.test(url) would leak internal regex state into these legacy static properties.

Thanks to @sosukesuzuki for the contribution!

SIMD optimizations across Bun.stripANSI, Bun.stringWidth, and the shared ANSI parsing helpers used by Bun.sliceAnsi, Bun.wrapAnsi, and Node's readline.getStringWidth.

Key improvements:

Compared to npm string-width, Bun is 4–822× faster depending on input size and content, and correctly handles all three OSC terminator variants (BEL, ESC \, and C1 ST) where the npm package only recognizes BEL.

Fixed a thread-pool bug that left the bundler running with one fewer worker thread than intended. Most impactful on low-core machines where one thread is a larger share of the pool:

Benchmark: bun build on an 11,669-module project (three.js + @mui/material + @mui/icons-material, 10.45 MB output).

Bun.Glob.scan() no longer opens and reads the same directory twice for patterns with a **/X/... boundary (e.g. **/node_modules/**/*.js). Gains scale with how much of the tree sits under the boundary — up to 2x on deeply nested trees. Patterns without a boundary (e.g. **/*.ts) are unchanged.

const glob = new Bun.Glob("**/node_modules/**/*.js");

// This is now up to 2x faster
for await (const path of glob.scan({ cwd: "./my-project" })) {
// ...
}

Additionally, Bun.Glob on Windows now pushes wildcard filters down to the kernel via NtQueryDirectoryFile, so non-matching entries are discarded before reaching userspace — up to 2.4× faster for simple patterns like *.js or pkg-*/lib/*.js in directories with a low match ratio. Patterns using **, ?, [...], or {...} bypass the filter and behave as before.

In the next version of Bun

Threadpool & JIT threads now respect cgroup CPU limits instead of physical cores. This improves resource utilization in Docker & k8shttps://t.co/HCPy7jRCyG

Bun now reuses CONNECT tunnels for HTTPS-through-proxy requests. Previously, every proxied HTTPS request performed a fresh CONNECT handshake and TLS negotiation. Now, the tunnel and inner TLS session are pooled and reused across sequential requests to the same target through the same proxy with the same credentials — matching the behavior of Node.js + undici.

This dramatically reduces latency and connection overhead when making multiple HTTPS requests through a proxy:

// All three requests now reuse a single CONNECT tunnel
// instead of establishing 3 separate tunnels + TLS handshakes
for (let i = 0; i 3; i++) {
const res = await fetch("https://example.com/api", {
proxy: "http://user:pass@proxy.example.com:8080",
});
console.log(res.status);
}

Tunnels are keyed by proxy host/port, proxy credentials, target host/port, and TLS configuration — so different targets or different credentials correctly use separate tunnels.

This also fixes intermittent Malformed_HTTP_Response errors that some users encountered when using fetch with HTTPS proxies.

Thanks to @cirospaciari for the contribution!

Bun.serve() now sets TCP_DEFER_ACCEPT on Linux (and SO_ACCEPTFILTER "dataready" on FreeBSD), the same optimization nginx uses to reduce latency for incoming HTTP connections.

Previously, accepting a new connection required two event loop wake-ups — one for the accept and another to discover the socket was readable. With TCP_DEFER_ACCEPT, the kernel defers the accept until the client has actually sent data (the HTTP request or TLS ClientHello), collapsing the two wake-ups into one:

Before:

After:

This is especially impactful for short-lived connections (e.g. HTTP/1.1 with Connection: close). Bun.listen() and net.createServer() are unchanged, since they may serve protocols where the server sends first. No effect on macOS or Windows.