Bun
@bunjavascript

Bun is a fast, all-in-one toolkit for installing, bundling, running and testing JavaScript & TypeScript. To install: `npm i -g bun`

bun.com
Joined July 2022
In the next version of Bun Idle CPU usage drops by 67%
Bun v1.4.3: 67–89% less CPU while your server sleeps, compared with v1.4.2. Illustrated as a night sky with the Bun logo asleep as the moon. One idle minute: v1.4.2 wakes up every second, because any occasional request kept the 1-second GC timer running. v1.4.3 wakes only for the health check, every 10 seconds. CPU milliseconds used in 2 idle minutes on Bun 1.3.14, 1.4.0, 1.4.2 and 1.4.3: Express: 430, 308, 282, 57 (4.9× less than 1.4.2) Fastify: 450, 284, 267, 57 (4.7× less) Elysia: 473, 280, 197, 21 (9.4× less) Hono: 417, 263, 195, 21 (9.3× less) Next.js SSR: 7,029, 628, 815, 268 Also 6–11% less idle memory than v1.4.2. Measured after a 30-second load test with one health check every 10 seconds, on Linux x64. 1.3.14 and 1.4.0 are the mean of 2 runs; 1.4.2 and 1.4.3 are the median of 4.

ALT Bun v1.4.3: 67–89% less CPU while your server sleeps, compared with v1.4.2. Illustrated as a night sky with the Bun logo asleep as the moon. One idle minute: v1.4.2 wakes up every second, because any occasional request kept the 1-second GC timer running. v1.4.3 wakes only for the health check, every 10 seconds. CPU milliseconds used in 2 idle minutes on Bun 1.3.14, 1.4.0, 1.4.2 and 1.4.3: Express: 430, 308, 282, 57 (4.9× less than 1.4.2) Fastify: 450, 284, 267, 57 (4.7× less) Elysia: 473, 280, 197, 21 (9.4× less) Hono: 417, 263, 195, 21 (9.3× less) Next.js SSR: 7,029, 628, 815, 268 Also 6–11% less idle memory than v1.4.2. Measured after a 30-second load test with one health check every 10 seconds, on Linux x64. 1.3.14 and 1.4.0 are the mean of 2 runs; 1.4.2 and 1.4.3 are the median of 4.

51
53
1,481
75,160
Replying to @openclonne

ALT Leonardo Dicaprio Look GIF by Once Upon A Time In Hollywood
19
1,403
In the next version of Bun Enabling profile-guided optimization for bytecode improves startup time by up to 2x `bun build --compile --bytecode --bytecode-order=./file`
18
12
405
17,799
VIA QUOTE POST PRIVILEGED & CONFIDENTIAL FOR SETTLEMENT PURPOSES ONLY (FED. R. EVID. 408) September 22, 2026 Mr. Alexandr Wang @alexandr_wang Re: Unauthorized Use of the BUN® Design Mark, U.S. Reg. No. 7,585,721; Proposed “Muse Merch Store”; Demand to Cease and Desist; Notice of Litigation Hold Mr. Wang: Bun (“Bun,” “Registrant,” or “the Bun”) is the owner of all right, title, and interest in and to U.S. Registration No. 7,585,721, issued December 3, 2024 on the Principal Register, for a mark consisting of “a bread bun with a smiling face,” wherein “the bun has black and white eyes,” “pink cheeks and a pink and dark pink mouth outlined in black,” the colors tan, dark tan, pink, dark pink, black and white being claimed as a feature of the mark (the “BUN® Mark”), which registration constitutes prima facie evidence of the validity of the BUN® Mark and of Bun’s exclusive right to use the same pursuant to 15 U.S.C. § 1057(b), and constructive notice of Bun’s claim of ownership thereof pursuant to 15 U.S.C. § 1072, such that ignorance of the Bun shall be no defense. The United States Patent and Trademark Office has further classified the BUN® Mark under Design Search Code 02.01.34 (“Monsters (not robots)”), a classification Bun has at all times accepted without objection. It has come to Bun’s attention that you, together with your affiliates, agents, successors, assigns, and any superintelligences acting in concert therewith (collectively, “You”), have announced an intent to open a “muse merch store” and have commenced “market research” in connection therewith, publicly displaying goods including without limitation one (1) t-shirt, one (1) bucket hat, one (1) beanie, one (1) sock (singular), one (1) pin set (3-pack), and assorted keychains, patches, plush and tote bags (collectively, the “Infringing Goods”), each bearing a tan, round figure having black eyes, pink cheeks and a smiling face (the “Musey”), which is, upon information and belief, also a monster, and not a robot. Under the factors set forth in AMF Inc. v. Sleekcraft Boats, 599 F.2d 341 (9th Cir. 1979), the likelihood of confusion is overwhelming: the marks are similar in sight, sound (none), and meaning (bun); the goods are proximate; Bun has long contemplated expansion into bucket hats; and consumers who have expressed a willingness to exchange a right kidney for the Infringing Goods cannot be said to be exercising the degree of care ordinarily expected of a reasonably prudent purchaser. Accordingly, Bun hereby demands that You immediately (i) cease and desist from any and all manufacture, sale, offering for sale, patting, and market research of or relating to the Infringing Goods; (ii) deliver up all Infringing Goods for destruction pursuant to 15 U.S.C. § 1118, or for cuddling, at Bun’s sole discretion; (iii) provide a full accounting of all profits, market capitalization, and kidneys received; and (iv) preserve all documents, electronically stored information, and plush, whether stuffed or unstuffed, pending final resolution of this matter. Nothing herein constitutes a complete statement of the relevant facts or a waiver of any rights, remedies, or crumbs, including without limitation those arising under 15 U.S.C. §§ 1114, 1116, 1117, and 1125(a) and (c) (Bun being, upon information and belief, famous), all of which are expressly reserved. Time is of the essence. Govern yourself accordingly. Very truly yours, Bun Enclosures: Exhibits A–B cc: The Musey (via pat) Exhibits
Alexandr Wang
@alexandr_wang
Sep 22
we are considering opening a muse merch store i am doing market research how excited you would be by muse merch, from a scale of "meh" to "you can have my right kidney"?
49
10
395
80,613
Replying to @barsisyphus @github @turbopuffer @posthog @exedev @AntithesisHQ @TigerBeetleDB @digitalocean @ClaudeDevs
9? should be at least 2
1
33
2,289
Replying to @wesbos
smol pr
2
91
7,222
Bun v1.4.2 is compiling
19
4
499
21,315
Bun hit 32.8 million monthly downloads last month
8
8
354
185,105
Bun v1.4.1 is compiling
17
7
564
40,619
In the next version of Bun Bun starts 1ms faster
Benchmark 1: bun --print 1234 Time (mean ± σ): 3.8 ms ± 0.2 ms [User: 2.8 ms, System: 1.0 ms] Range (min … max): 3.4 ms … 4.5 ms 795 runs Benchmark 2: bun-1.4.0 --print 1234 Time (mean ± σ): 4.9 ms ± 0.3 ms [User: 3.2 ms, System: 1.7 ms] Range (min … max): 4.1 ms … 5.6 ms 544 runs Benchmark 3: node --print 1234 Time (mean ± σ): 26.9 ms ± 1.8 ms [User: 14.6 ms, System: 11.9 ms] Range (min … max): 23.7 ms … 30.7 ms 113 runs Summary bun --print 1234 ran 1.27 ± 0.11 times faster than bun-1.4.0 --print 1234 7.01 ± 0.58 times faster than node --print 1234

ALT Benchmark 1: bun --print 1234 Time (mean ± σ): 3.8 ms ± 0.2 ms [User: 2.8 ms, System: 1.0 ms] Range (min … max): 3.4 ms … 4.5 ms 795 runs Benchmark 2: bun-1.4.0 --print 1234 Time (mean ± σ): 4.9 ms ± 0.3 ms [User: 3.2 ms, System: 1.7 ms] Range (min … max): 4.1 ms … 5.6 ms 544 runs Benchmark 3: node --print 1234 Time (mean ± σ): 26.9 ms ± 1.8 ms [User: 14.6 ms, System: 11.9 ms] Range (min … max): 23.7 ms … 30.7 ms 113 runs Summary bun --print 1234 ran 1.27 ± 0.11 times faster than bun-1.4.0 --print 1234 7.01 ± 0.58 times faster than node --print 1234

39
15
976
74,210
Peak memory usage doesn't change much
Table: "Bun v1.4.1 peak memory usage." Peak resident memory (kernel high-water mark) during 60 seconds of sustained load, lower is better. Columns: Bun 1.4.1, change vs 1.4.0, Bun 1.4.0, Bun 1.3.14, Node.js 26.7. Fastify: 94 MB (−27%), 128, 163, 154. Next.js SSR: 265 MB (−11%), 299, 1653, 387. Vite dev: 280 MB (no change), 296, 495, 243. Elysia: 54 MB (no change), 57, 75, 115. Express: 86 MB (no change), 89, 153, 143. Hono: 48 MB (no change), 47, 63, 121. Same method: fixed request rate for 60 s, 64 connections, Linux x64.

ALT Table: "Bun v1.4.1 peak memory usage." Peak resident memory (kernel high-water mark) during 60 seconds of sustained load, lower is better. Columns: Bun 1.4.1, change vs 1.4.0, Bun 1.4.0, Bun 1.3.14, Node.js 26.7. Fastify: 94 MB (−27%), 128, 163, 154. Next.js SSR: 265 MB (−11%), 299, 1653, 387. Vite dev: 280 MB (no change), 296, 495, 243. Elysia: 54 MB (no change), 57, 75, 115. Express: 86 MB (no change), 89, 153, 143. Hono: 48 MB (no change), 47, 63, 121. Same method: fixed request rate for 60 s, 64 connections, Linux x64.

1
1
52
16,023
Bun v1.4.1 reduces idle memory usage
Table: "Bun v1.4.1 reduces idle memory usage." Resident memory 3 minutes after 60 seconds of sustained load, lower is better. Columns: Bun 1.4.1, change vs 1.4.0, Bun 1.4.0, Bun 1.3.14, Node.js 26.7. Next.js SSR: 142 MB (−36%), 222, 1303, 195. Vite dev: 157 MB (−17%), 189, 303, 155. Express: 54 MB (−17%), 65, 77, 81. Fastify: 57 MB (−16%), 68, 80, 91. Elysia: 44 MB (no change), 46, 69, 96. Hono: 34 MB (no change), 35, 53, 92. Method: 60 s at a fixed request rate (40k req/s Elysia and Hono, 25k Express and Fastify, 5k Vite dev, 3k Next.js SSR), 64 connections, then 180 s idle; RSS sampled every 100 ms on Linux x64.

ALT Table: "Bun v1.4.1 reduces idle memory usage." Resident memory 3 minutes after 60 seconds of sustained load, lower is better. Columns: Bun 1.4.1, change vs 1.4.0, Bun 1.4.0, Bun 1.3.14, Node.js 26.7. Next.js SSR: 142 MB (−36%), 222, 1303, 195. Vite dev: 157 MB (−17%), 189, 303, 155. Express: 54 MB (−17%), 65, 77, 81. Fastify: 57 MB (−16%), 68, 80, 91. Elysia: 44 MB (no change), 46, 69, 96. Hono: 34 MB (no change), 35, 53, 92. Method: 60 s at a fixed request rate (40k req/s Elysia and Hono, 25k Express and Fastify, 5k Vite dev, 3k Next.js SSR), 64 connections, then 180 s idle; RSS sampled every 100 ms on Linux x64.

15
23
537
47,653
In the next version of Bun AsyncLocalStorage gets about 13% faster
Wall clock, min of 3 interleaved runs × min of 5 iterations, taskset to 8 cores, store active (node v26.3.0 on the same box for reference): ns/op node 26 bun main this PR als.run(v, fn) 410 28.8 15.9 3× nested run() 2833 338 57.8 await <value> 36.8 44.1 34.5 await Promise.resolve() 55.9 48.6 35.5 for await (async generator) 162 110 88.3 N × pending.then(f) + Promise.all 435 345 281

ALT Wall clock, min of 3 interleaved runs × min of 5 iterations, taskset to 8 cores, store active (node v26.3.0 on the same box for reference): ns/op node 26 bun main this PR als.run(v, fn) 410 28.8 15.9 3× nested run() 2833 338 57.8 await <value> 36.8 44.1 34.5 await Promise.resolve() 55.9 48.6 35.5 for await (async generator) 162 110 88.3 N × pending.then(f) + Promise.all 435 345 281

5
4
311
29,394
Bun v1.4.1 is a big upgrade to Bun’s bundler. On a 200-route React app over simulated 4G, navigating between routes is 38% faster than Bun v1.4.0, and 10% faster than Vite v8.2.2.
Slide titled “Route navigation on 4G”, subtitle “click → lazy route’s chunks fetched, parsed, and rendered by React · lower is better”. Three horizontal bars: Bun 1.4.0, 1104 ms (dark gray); Vite 8, 757 ms (gray); Bun 1.4.1, 681 ms (pink-to-orange gradient, labeled −38%). Table below with columns Bun 1.4.0 / Vite 8 / Bun 1.4.1: Requests per navigation 108 / 108 / 61; LCP, cold first load 736 ms / 560 ms / 576 ms; JS chunks emitted 918 / 908 / 750; Total JS shipped (gzip) 1.75 MB / 1.67 MB / 1.61 MB. Footnote: 200 lazy routes, 800 components, 30 npm deps, React Compiler on in both, headless Chrome, 170 ms RTT / 9 Mbps, cold cache, median of 7 runs × 12 routes; Bun built with bun build –splitting –min-chunk-size=16384 –react-compiler; Vite 8.2 with @vitejs/plugin-react 6 compiler: true.

ALT Slide titled “Route navigation on 4G”, subtitle “click → lazy route’s chunks fetched, parsed, and rendered by React · lower is better”. Three horizontal bars: Bun 1.4.0, 1104 ms (dark gray); Vite 8, 757 ms (gray); Bun 1.4.1, 681 ms (pink-to-orange gradient, labeled −38%). Table below with columns Bun 1.4.0 / Vite 8 / Bun 1.4.1: Requests per navigation 108 / 108 / 61; LCP, cold first load 736 ms / 560 ms / 576 ms; JS chunks emitted 918 / 908 / 750; Total JS shipped (gzip) 1.75 MB / 1.67 MB / 1.61 MB. Footnote: 200 lazy routes, 800 components, 30 npm deps, React Compiler on in both, headless Chrome, 170 ms RTT / 9 Mbps, cold cache, median of 7 runs × 12 routes; Bun built with bun build –splitting –min-chunk-size=16384 –react-compiler; Vite 8.2 with @vitejs/plugin-react 6 compiler: true.

18
26
690
40,731
In the next version of Bun `bun build` tree-shakes property accesses through dynamic imports
Tree-shaking through dynamic import()# bun build now removes the exports of a dynamically imported module that your code never reads. main.ts // is.ts exports isNumber, isOdd, and isEven const { isOdd } = await import("./is"); console.log(isOdd(3)); With bun build ./main.ts --splitting --outdir dist, is.ts becomes its own chunk: dist/is-1qza7reb.js function isNumber(n) { return typeof n === "number"; } function isOdd(n) { return isNumber(n) && n % 2 === 1; } function isEven(n) { return !isOdd(n); } export { isEven, isNumber, isOdd };

ALT Tree-shaking through dynamic import()# bun build now removes the exports of a dynamically imported module that your code never reads. main.ts // is.ts exports isNumber, isOdd, and isEven const { isOdd } = await import("./is"); console.log(isOdd(3)); With bun build ./main.ts --splitting --outdir dist, is.ts becomes its own chunk: dist/is-1qza7reb.js function isNumber(n) { return typeof n === "number"; } function isOdd(n) { return isNumber(n) && n % 2 === 1; } function isEven(n) { return !isOdd(n); } export { isEven, isNumber, isOdd };

6
5
306
13,452
In the next version of Bun Bun's bundler gets smarter about tree-shaking ESM that uses `export * as ns` syntax
Smaller bundles for libraries that use export * as# Libraries like zod and Effect group their exports with export * as. When you called z.object(), Bun 1.4.0 kept every export of that group, because it built a namespace object with a getter for each one. Now z.object points straight at the object function, and the exports you don't use are tree-shaken. out.js var User = exports_external.object({ a: exports_external.string() }); var User = object({ a: string2() }); Each program below calls two or three functions from one library, built with bun build --minify: Package Bun 1.4.0 Bun 1.4.1 Change fp-ts 2.16 21.8 KB 3.2 KB −85% zod 4.5 375.3 KB 77.3 KB −79% ox 1.7 15.4 KB 4.7 KB −70% effect 3.22 369.1 KB 163.6 KB −56% @sinclair/typebox 0.34 107.1 KB 53.3 KB −50%

ALT Smaller bundles for libraries that use export * as# Libraries like zod and Effect group their exports with export * as. When you called z.object(), Bun 1.4.0 kept every export of that group, because it built a namespace object with a getter for each one. Now z.object points straight at the object function, and the exports you don't use are tree-shaken. out.js var User = exports_external.object({ a: exports_external.string() }); var User = object({ a: string2() }); Each program below calls two or three functions from one library, built with bun build --minify: Package Bun 1.4.0 Bun 1.4.1 Change fp-ts 2.16 21.8 KB 3.2 KB −85% zod 4.5 375.3 KB 77.3 KB −79% ox 1.7 15.4 KB 4.7 KB −70% effect 3.22 369.1 KB 163.6 KB −56% @sinclair/typebox 0.34 107.1 KB 53.3 KB −50%

9
11
417
18,758
In the next version of Bun `bun build --splitting` injects `<link rel="modulepreload">`, helping webpages load faster by reducing network waterfalls
8
25
852
46,137
In the next version of Bun `Bun.serve({ http2: true })` enables HTTP/2 support. The same API just works for HTTP/1.1, HTTP/2, and HTTP/3.
Bar chart: "Bun.serve() now speaks HTTP/2". Requests per second, HTTP/2 over TLS, Linux x64. Three bars per scenario: Bun.serve(), node:http2 in Bun, node:http2 in Node.js v26. Hello World (GET, 13 B response): 291,512 / 55,619 / 42,733 — 6.8× faster POST 4 KB body: 136,077 / 45,366 / 30,112 — 4.5× faster 2 KB URL (GET, long path + query): 113,648 / 43,168 / 31,249 — 3.6× faster 64 KB response: 17,357 / 13,771 / 12,979 — 1.3× faster Streaming (256 KB in → 32 KB out): 4,570 / 4,563 / 2,164 — 2.1× faster Speedup is Bun.serve() vs Node.js v26.3. Bun v1.4.1, 64 cores, loopback, fresh server process per run. h2load -c 64 -m 16 -t 8 -n 100000.

ALT Bar chart: "Bun.serve() now speaks HTTP/2". Requests per second, HTTP/2 over TLS, Linux x64. Three bars per scenario: Bun.serve(), node:http2 in Bun, node:http2 in Node.js v26. Hello World (GET, 13 B response): 291,512 / 55,619 / 42,733 — 6.8× faster POST 4 KB body: 136,077 / 45,366 / 30,112 — 4.5× faster 2 KB URL (GET, long path + query): 113,648 / 43,168 / 31,249 — 3.6× faster 64 KB response: 17,357 / 13,771 / 12,979 — 1.3× faster Streaming (256 KB in → 32 KB out): 4,570 / 4,563 / 2,164 — 2.1× faster Speedup is Bun.serve() vs Node.js v26.3. Bun v1.4.1, 64 cores, loopback, fresh server process per run. h2load -c 64 -m 16 -t 8 -n 100000.

5
12
437
19,203
`--bytecode` used to cost ~7x your source size on disk and ~4x in memory, in exchange for faster startup. Now its ~3x on disk, almost free in memory, and starts faster than before. This is a large test app, so the absolute numbers are higher than what most would see.
2
1
70
6,453
In the next version of Bun Compiled executables with bytecode start 17% faster, get 30% smaller, and use 30% less memory on start
Dark graphic with the Bun logo and the command bun build --compile --bytecode --splitting. Headline: "In the next version of Bun, compiled executables get". Three large stat cards: "34% smaller binary — 428 MB → 284 MB" in pink, "17% faster startup — 458 ms → 382 ms" in orange, "32% less RAM — 383 MB → 260 MB" in green. Footer: "57 npm packages · 36 MB minified bundle · Linux x64 · ESM · medians vs Bun v1.4.0" and a pill reading "bytecode is now mmap'd & read in place".

ALT Dark graphic with the Bun logo and the command bun build --compile --bytecode --splitting. Headline: "In the next version of Bun, compiled executables get". Three large stat cards: "34% smaller binary — 428 MB → 284 MB" in pink, "17% faster startup — 458 ms → 382 ms" in orange, "32% less RAM — 383 MB → 260 MB" in green. Footer: "57 npm packages · 36 MB minified bundle · Linux x64 · ESM · medians vs Bun v1.4.0" and a pill reading "bytecode is now mmap'd & read in place".

12
17
860
68,200
In the next version of Bun Buffer's read/write methods get up to 7x faster
Benchmark card titled "Buffer reads & writes get faster — Coming in Bun v1.4.1. Now JIT‑compiled into direct loads & stores." Highlight tiles: 7.7× faster writeUInt8, 7.3× faster writeDoubleLE, 3.1× faster readInt32LE across 1,024 buffers, all vs Bun 1.4.0. A horizontal bar chart compares nanoseconds per call (lower is better, Apple Silicon) for Bun 1.4.1, Bun 1.4.0 and Node 26.5, with the speedup vs Bun 1.4.0 on the right. Varying offset over one 4 KB buffer: readInt8 0.24 vs 0.32 ns (1.3×), readUInt8 0.24 vs 0.48 (2.0×), readInt16BE 0.37 vs 0.56 (1.5×), readDoubleLE 0.61 vs 0.81 (1.3×), writeUInt8 0.28 vs 2.16 (7.7×), writeInt16BE 0.33 vs 2.29 (6.9×), writeUInt32BE 0.38 vs 2.63 (6.9×), writeFloatLE 0.28 vs 2.11 (7.5×), writeDoubleLE 0.27 vs 1.98 (7.3×). One access on each of 1,024 buffers: readInt32LE 0.65 vs 2.01 (3.1×), writeInt32LE 0.57 vs 1.2 (2.1×), readDoubleLE 0.66 vs 1.46 (2.2×). Node 26.5 is shown for context and ranges from 0.24 to 2.93 ns on the same tests.

ALT Benchmark card titled "Buffer reads & writes get faster — Coming in Bun v1.4.1. Now JIT‑compiled into direct loads & stores." Highlight tiles: 7.7× faster writeUInt8, 7.3× faster writeDoubleLE, 3.1× faster readInt32LE across 1,024 buffers, all vs Bun 1.4.0. A horizontal bar chart compares nanoseconds per call (lower is better, Apple Silicon) for Bun 1.4.1, Bun 1.4.0 and Node 26.5, with the speedup vs Bun 1.4.0 on the right. Varying offset over one 4 KB buffer: readInt8 0.24 vs 0.32 ns (1.3×), readUInt8 0.24 vs 0.48 (2.0×), readInt16BE 0.37 vs 0.56 (1.5×), readDoubleLE 0.61 vs 0.81 (1.3×), writeUInt8 0.28 vs 2.16 (7.7×), writeInt16BE 0.33 vs 2.29 (6.9×), writeUInt32BE 0.38 vs 2.63 (6.9×), writeFloatLE 0.28 vs 2.11 (7.5×), writeDoubleLE 0.27 vs 1.98 (7.3×). One access on each of 1,024 buffers: readInt32LE 0.65 vs 2.01 (3.1×), writeInt32LE 0.57 vs 1.2 (2.1×), readDoubleLE 0.66 vs 1.46 (2.2×). Node 26.5 is shown for context and ranges from 0.24 to 2.93 ns on the same tests.

17
19
663
36,801
Bun 1.4 is here piped.video/watch?v=i38DgEua…

Bun v1.4

Bun 1.4 is here. It uses less memory, less CPU, and starts faster. ...

youtube.com
61
108
1,338
141,717
almost done
1
72
17,949
JavaScript files use Bun's JS parser to AST diff and reformat it. This makes diffs of minified source code readable, which makes it a little harder for supply chain attacks to hide.
2
1
64
6,913
In the next version of Bun `bun pm diff <package@version> <package@version2>` shows code changes between versions (un-minified)
21
10
408
74,010
In the next version of Bun Web APIs like `URL`, `Headers`, and `URLSearchParams` get up to 4x faster
Bun v1.4 URL, Headers & URLSearchParams — operations per second, longer is faster Bun v1.4 Bun v1.3.14 Node v26 9.62M ops/s 4.6x faster than v1.3.14 new URL (url) "https://example.com/search?q=bun#results" 2.10M ops/s 3.51M ops/s 4.37M ops/s 3.6x faster than v1.3.14 new URL (path, base) "../assets/logo.svg" against a page URL 1.22M ops/s 1.93M ops/s 4.15M ops/s 18.4x faster than v1.3.14 new URL (LongUrl) 2 KB of query string 225K ops/s 641K ops/s 10.1M ops/s 5.1x faster than v1.3.14 URL. parse (url) 1.97M ops/s 1.92M ops/s 2.48M ops/s 1.6x faster than v1.3.14 new Headers({...}) 3 headers from an object 1.60M ops/s 610K ops/s 2.17M ops/s 1.4x faster than v1.3.14 new URLSearchParams ({...}) 5 params from an object Linux x64 • same machine • mitata • bars scaled per benchmark 1.55M ops/s 1.66M ops/s bench/snippets/{url-kinds,headers, urlsearchparams}.mjs

ALT Bun v1.4 URL, Headers & URLSearchParams — operations per second, longer is faster Bun v1.4 Bun v1.3.14 Node v26 9.62M ops/s 4.6x faster than v1.3.14 new URL (url) "https://example.com/search?q=bun#results" 2.10M ops/s 3.51M ops/s 4.37M ops/s 3.6x faster than v1.3.14 new URL (path, base) "../assets/logo.svg" against a page URL 1.22M ops/s 1.93M ops/s 4.15M ops/s 18.4x faster than v1.3.14 new URL (LongUrl) 2 KB of query string 225K ops/s 641K ops/s 10.1M ops/s 5.1x faster than v1.3.14 URL. parse (url) 1.97M ops/s 1.92M ops/s 2.48M ops/s 1.6x faster than v1.3.14 new Headers({...}) 3 headers from an object 1.60M ops/s 610K ops/s 2.17M ops/s 1.4x faster than v1.3.14 new URLSearchParams ({...}) 5 params from an object Linux x64 • same machine • mitata • bars scaled per benchmark 1.55M ops/s 1.66M ops/s bench/snippets/{url-kinds,headers, urlsearchparams}.mjs

22
17
676
185,404
In the next version of Bun The `cgroup` option in `Bun.spawn` lets you limit cpu & memory usage of spawned processes on Linux
27
22
746
33,623
In the next version of Bun `bun dedupe` deduplicates semver-compatible resolved package versions
8
14
574
21,605
In the next version of Bun `bun audit fix` updates vulnerable dependencies
7
20
507
17,749
In the next version of Bun `bun prune` cleans unnecessary folders from node_modules
30
58
1,526
124,024
it’s almost time
43
27
1,041
34,290
Bun v1.4 is compiling
77
68
2,417
230,341
ratio improved!!
3
20
2,029
In the next version of Bun Node.js compatibility gets a big upgrade. Since Bun v1.3.14, an additional +1,493 tests from the Node.js test suite pass in Bun.
Line chart titled "Bun's Node.js test suite progress" — official Node.js test suite files passing on every commit. The line climbs from about 1,460 at Bun v1.2.0 (Jan 2025) to about 2,230 by v1.3.0 (Oct 2025), stays flat until May 2026, then shoots almost straight up to 3,743 on main today (Aug 2026), crossing a dashed line labeled "The bar to ship Bun v1.4: 3,693." Callouts read "+50 over the bar" and "+1,517 since v1.3.0."

ALT Line chart titled "Bun's Node.js test suite progress" — official Node.js test suite files passing on every commit. The line climbs from about 1,460 at Bun v1.2.0 (Jan 2025) to about 2,230 by v1.3.0 (Oct 2025), stays flat until May 2026, then shoots almost straight up to 3,743 on main today (Aug 2026), crossing a dashed line labeled "The bar to ship Bun v1.4: 3,693." Callouts read "+50 over the bar" and "+1,517 since v1.3.0."

Bun
@bunjavascript
Aug 7
In the last 16 days, an additional +473 new tests from Node.js' test suite pass in Bun v1.4
15
11
442
108,180
In the next version of Bun RegExp gets up to 281x faster
Dark benchmark card titled "RegExp in Bun". Top right, struck through: the GitHub issue title "Node.js is 300× faster than Bun at isbot regexp" (oven-sh/bun#5197, closed). Huge headline: "281× faster on the isbot regex." Subtext: "110 alternatives, four lookbehinds, 263,487 real user-agent strings. Same script, same machine." Three horizontal bars, drawn to scale, lower is better: Bun v1.3.14 (before) 32,395 ms — spans the full width; Node.js v26 (V8/Irregexp) 141 ms — a thin sliver; Bun v1.4 (after) 115 ms — an even thinner pink sliver. Footer: Apple Silicon, benchmark from github.com/quick-lint/bun-vs-node; improvements: JIT-compiled lookbehinds, alternation dispatch, prefix factoring, wider Boyer-Moore search. The isbot regex source is faintly visible as background texture.

ALT Dark benchmark card titled "RegExp in Bun". Top right, struck through: the GitHub issue title "Node.js is 300× faster than Bun at isbot regexp" (oven-sh/bun#5197, closed). Huge headline: "281× faster on the isbot regex." Subtext: "110 alternatives, four lookbehinds, 263,487 real user-agent strings. Same script, same machine." Three horizontal bars, drawn to scale, lower is better: Bun v1.3.14 (before) 32,395 ms — spans the full width; Node.js v26 (V8/Irregexp) 141 ms — a thin sliver; Bun v1.4 (after) 115 ms — an even thinner pink sliver. Footer: Apple Silicon, benchmark from github.com/quick-lint/bun-vs-node; improvements: JIT-compiled lookbehinds, alternation dispatch, prefix factoring, wider Boyer-Moore search. The isbot regex source is faintly visible as background texture.

39
33
1,005
76,438
In the next version of Bun `Bun.YAML.parse` supports cyclic anchors & aliases
In the next version of Bun ▎ ▎ Bun.YAML.parse supports cyclic anchors & aliases ▎ ▎ tweet: &tweet ▎ text: | ▎ In the next version of Bun ▎ ▎ Bun.YAML.parse supports cyclic anchors & aliases ▎ quote_tweet: *tweet ▎ const { tweet } = Bun.YAML.parse(src) ▎ tweet.quote_tweet.quote_tweet.quote_tweet.text ▎ // "In the next version of Bun\n\nBun.YAML.parse supports cyclic anchors & aliases\n"

ALT In the next version of Bun ▎ ▎ Bun.YAML.parse supports cyclic anchors & aliases ▎ ▎ tweet: &tweet ▎ text: | ▎ In the next version of Bun ▎ ▎ Bun.YAML.parse supports cyclic anchors & aliases ▎ quote_tweet: *tweet ▎ const { tweet } = Bun.YAML.parse(src) ▎ tweet.quote_tweet.quote_tweet.quote_tweet.text ▎ // "In the next version of Bun\n\nBun.YAML.parse supports cyclic anchors & aliases\n"

6
8
331
18,893
In the next version of Bun `Bun.XML.parse` is a SIMD-accelerated XML parser builtin to Bun
XML parsing S3 ListObjects response, 231 KB. Lower is better. 19× faster than fast-xml-parser Bun.XML.parse 1.3 ms txml 4.8 ms fast-xml-parser 24.8 ms @xmldom/xmldom 33.6 ms

ALT XML parsing S3 ListObjects response, 231 KB. Lower is better. 19× faster than fast-xml-parser Bun.XML.parse 1.3 ms txml 4.8 ms fast-xml-parser 24.8 ms @xmldom/xmldom 33.6 ms

20
16
549
33,338
In the last 16 days, an additional +473 new tests from Node.js' test suite pass in Bun v1.4
Bun
@bunjavascript
Jul 22
Bun v1.4 will be our biggest jump in Node.js compatibility since Bun v1.0
Line chart titled "Bun's Node.js test suite progress", subtitled "Official Node.js test suite files run on every commit". The line starts at 1,378 test files at Bun v1.2.0 (January 2025), climbs through the 1.2 series to 2,250 at v1.3.14, holds flat across the 1.3 releases, then spikes to 3,188 files on main today (July 2026). A dashed target line at 3,693 reads "The bar to ship Bun v1.4: 3,693", with "505 to go" marking the gap between main and the target.

ALT Line chart titled "Bun's Node.js test suite progress", subtitled "Official Node.js test suite files run on every commit". The line starts at 1,378 test files at Bun v1.2.0 (January 2025), climbs through the 1.2 series to 2,250 at v1.3.14, holds flat across the 1.3 releases, then spikes to 3,188 files on main today (July 2026). A dashed target line at 3,693 reads "The bar to ship Bun v1.4: 3,693", with "505 to go" marking the gap between main and the target.

15
13
490
64,285
more detail about the bug
WHAT WAS ACTUALLY WRONG • OVEN-SH/BUN #36624 One manual GC root turned every request into a cycle the collector couldn't break. THE WHOLE BUG, WITHOUT NEXT.JS keeps alive - the GC can't trace this edge 3 4 5 await als. run(store, async () => { const res = new Response(bytes) res.body store.responses.push(res) Strong<ReadableStream> a manual GC root ReadableStream created by reading body }) owns the Strong captured its async context Next's App Router does exactly this on every SSR request that calls fetch0 — its fetch dedupe reads .body on a buffered Response and keeps that Response in the request's AsyncLocalStorage store. 2 Response never finalizes per-request store AsyncLocalStorage line 4: store holds the Response The fix: once the Response wrapper's traced slot owns the stream, the body getter downgrades its Strong handle to weak. The untraceable edge becomes an ordinary one, and the whole per-request graph is collected when the request ends. ROOTED READABLESTREAMS AFTER 2,000 REQU

ALT WHAT WAS ACTUALLY WRONG • OVEN-SH/BUN #36624 One manual GC root turned every request into a cycle the collector couldn't break. THE WHOLE BUG, WITHOUT NEXT.JS keeps alive - the GC can't trace this edge 3 4 5 await als. run(store, async () => { const res = new Response(bytes) res.body store.responses.push(res) Strong<ReadableStream> a manual GC root ReadableStream created by reading body }) owns the Strong captured its async context Next's App Router does exactly this on every SSR request that calls fetch0 — its fetch dedupe reads .body on a buffered Response and keeps that Response in the request's AsyncLocalStorage store. 2 Response never finalizes per-request store AsyncLocalStorage line 4: store holds the Response The fix: once the Response wrapper's traced slot owns the stream, the body getter downgrades its Strong handle to weak. The untraceable edge becomes an ordinary one, and the whole per-request graph is collected when the request ends. ROOTED READABLESTREAMS AFTER 2,000 REQU

4
1
76
7,729
In the next version of Bun We fixed a GC retention cycle that made Next.js App Router SSR leak memory when a page called fetch()
Next.js 16 · App Router · next start. The SSR memory leak is gone in Bun v1.4.” Subtitle: “4,000 server-rendered pages: Bun v1.4 settles at 238 MB, under Node’s 410 MB. Bun v1.3.14 climbed to 1,983 MB and kept going.” A line chart of server memory (RSS) against requests served, 0 to 4,000, then a dashed tail to the value after 5 seconds idle. Bun v1.3.14 rises steadily to a 1,983 MB peak and settles at 1,901 MB; Node v26.5 flattens around 400 MB and settles at 410 MB; Bun v1.4 stays flat near 300–350 MB and settles at 238 MB. Footer: stock create-next-app (Next 16.2.3, React 19.2) with the bug report’s page — a React.cache-wrapped fetch(…, { cache: “no-store” }) in a dynamic route; 4,000 unique URLs at 50 concurrent; server RSS sampled from /proc every 200 requests; product API is a separate Node process; Linux x64; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

ALT Next.js 16 · App Router · next start. The SSR memory leak is gone in Bun v1.4.” Subtitle: “4,000 server-rendered pages: Bun v1.4 settles at 238 MB, under Node’s 410 MB. Bun v1.3.14 climbed to 1,983 MB and kept going.” A line chart of server memory (RSS) against requests served, 0 to 4,000, then a dashed tail to the value after 5 seconds idle. Bun v1.3.14 rises steadily to a 1,983 MB peak and settles at 1,901 MB; Node v26.5 flattens around 400 MB and settles at 410 MB; Bun v1.4 stays flat near 300–350 MB and settles at 238 MB. Footer: stock create-next-app (Next 16.2.3, React 19.2) with the bug report’s page — a React.cache-wrapped fetch(…, { cache: “no-store” }) in a dynamic route; 4,000 unique URLs at 50 concurrent; server RSS sampled from /proc every 200 requests; product API is a separate Node process; Linux x64; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

23
19
684
46,369
In the next version of Bun Saving streaming file uploads to disk via Bun.write uses 35x less memory compared to Bun v1.3.14
Benchmark card titled “Saving 5,000 uploads to disk · 2 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 uses 35× less memory than v1.3.14 and takes uploads at 1.65× Node’s requests per second.” Horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 316 MB, Bun v1.3.14 11,142 MB (bar fills the track), Node v26.5 213 MB. Smaller figures below: requests per second — Bun v1.4 999, Bun v1.3.14 552, Node 604; CPU time — Bun v1.4 16.3 s, Bun v1.3.14 20.8 s, Node 19.5 s. Route under test: app.post(”/upload”, async (c) => { await Bun.write(path, c.req.raw); return c.text(“ok”) }), with a note that Node saves it with await pipeline(Readable.fromWeb(c.req.raw.body), createWriteStream(path)). Footer: oha -c 100 -n 5000 -m POST -D 2mb.bin, same Hono 4.12 app on each runtime, each saving the body its idiomatic way, Linux x64, GNU time -v, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

ALT Benchmark card titled “Saving 5,000 uploads to disk · 2 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 uses 35× less memory than v1.3.14 and takes uploads at 1.65× Node’s requests per second.” Horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 316 MB, Bun v1.3.14 11,142 MB (bar fills the track), Node v26.5 213 MB. Smaller figures below: requests per second — Bun v1.4 999, Bun v1.3.14 552, Node 604; CPU time — Bun v1.4 16.3 s, Bun v1.3.14 20.8 s, Node 19.5 s. Route under test: app.post(”/upload”, async (c) => { await Bun.write(path, c.req.raw); return c.text(“ok”) }), with a note that Node saves it with await pipeline(Readable.fromWeb(c.req.raw.body), createWriteStream(path)). Footer: oha -c 100 -n 5000 -m POST -D 2mb.bin, same Hono 4.12 app on each runtime, each saving the body its idiomatic way, Linux x64, GNU time -v, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

18
16
542
29,428
In the next version of Bun Proxying file uploads uses 10x less memory than in v1.3.14
Benchmark card titled “Relaying 300 uploads to storage · 20 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 matches Node’s memory at a third of the CPU — v1.3.14 needed 11× more RAM.” Horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 205 MB, Bun v1.3.14 2,259 MB (bar fills the track), Node v26.5 203 MB. Smaller figures below: CPU time — Bun v1.4 5.0 s, Bun v1.3.14 8.0 s, Node 13.9 s; wall clock — 31.5 s, 31.5 s, 31.6 s (storage sets the pace). Route under test: app.post(”/relay”, (c) => fetch(bucketUrl, { method: “PUT”, body: c.req.raw.body, duplex: “half” })). Footer: oha -c 100 -n 300 -m POST -D 20mb.bin, same Hono 4.12 app on each runtime, storage endpoint capped at 200 MB/s with tc, Linux x64, GNU time -v, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

ALT Benchmark card titled “Relaying 300 uploads to storage · 20 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 matches Node’s memory at a third of the CPU — v1.3.14 needed 11× more RAM.” Horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 205 MB, Bun v1.3.14 2,259 MB (bar fills the track), Node v26.5 203 MB. Smaller figures below: CPU time — Bun v1.4 5.0 s, Bun v1.3.14 8.0 s, Node 13.9 s; wall clock — 31.5 s, 31.5 s, 31.6 s (storage sets the pace). Route under test: app.post(”/relay”, (c) => fetch(bucketUrl, { method: “PUT”, body: c.req.raw.body, duplex: “half” })). Footer: oha -c 100 -n 300 -m POST -D 20mb.bin, same Hono 4.12 app on each runtime, storage endpoint capped at 200 MB/s with tc, Linux x64, GNU time -v, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

10
9
392
19,647
In the next version of Bun Several bugs involving backpressure propagation have been fixed
Benchmark card titled “Proxying 2,000 downloads · 2 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 holds half the memory of Node while serving 2× the requests per second.” A horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 171 MB, Bun v1.3.14 245 MB, Node v26.5 326 MB. Below, smaller figures: requests per second — Bun v1.4 868, Bun v1.3.14 948, Node 443; CPU time — Bun v1.4 3.9 s, Bun v1.3.14 3.6 s, Node 6.3 s. The route under test is one line: app.get(”/proxy”, (c) => fetch(originUrl)). Footer: oha -c 100 -n 2000, same Hono 4.12 app on each runtime, origin serves at line rate, Linux x64, GNU time -v for max RSS and CPU, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

ALT Benchmark card titled “Proxying 2,000 downloads · 2 MB each — same Hono app, three runtimes.” Subtitle: “Bun v1.4 holds half the memory of Node while serving 2× the requests per second.” A horizontal bar chart of peak memory (max RSS of the server process, shorter is better): Bun v1.4 171 MB, Bun v1.3.14 245 MB, Node v26.5 326 MB. Below, smaller figures: requests per second — Bun v1.4 868, Bun v1.3.14 948, Node 443; CPU time — Bun v1.4 3.9 s, Bun v1.3.14 3.6 s, Node 6.3 s. The route under test is one line: app.get(”/proxy”, (c) => fetch(originUrl)). Footer: oha -c 100 -n 2000, same Hono 4.12 app on each runtime, origin serves at line rate, Linux x64, GNU time -v for max RSS and CPU, median of 5 runs; bun 1.4.0-canary f91d5c95c, bun 1.3.14, node 26.5.0.

6
7
372
22,660
In the next version of Bun Bun.serve can serve a whole folder
46
27
649
37,414
Bun v1.4 fixes over 3,000 GitHub issues since Bun v1.3 3,064 3,000 2,069 A +70% fixed 2,000 1,792 1,000 Bun v1.2 This cycle Bun fixes 85 öven-sh/bün: GitHüb issues closed as completed, per release cycle as of July 2026" Bun v1.3 issues for every 100 opened up from 49 Bun v1.4 coming next week

ALT Bun v1.4 fixes over 3,000 GitHub issues since Bun v1.3 3,064 3,000 2,069 A +70% fixed 2,000 1,792 1,000 Bun v1.2 This cycle Bun fixes 85 öven-sh/bün: GitHüb issues closed as completed, per release cycle as of July 2026" Bun v1.3 issues for every 100 opened up from 49 Bun v1.4 coming next week

31
18
895
70,180
In the next version of Bun bun:ffi gets up to 3x faster
BUN:FFI • REWRITTEN AS ENGINE-NATIVE FFI IN JAVASCRIPTCORE up to 3× faster ffi Symbols & callbacks are engine cells • hot call sites JIT to a bare call; ret • 70× less memory/ symbol 3.0x 3.3x O bun TinyccO bun •JSC-native 2.3x 1.4x TINYCC = 1x noop call 2.27 ns → 763 ps new CString( 99.5 → 30 ns yoga layout x1k opentui benchmark speedup vs previous TinyCC-based bun:ffi macOS arm64 • opentui: unmodified 347-symbol app scrollbox 10k opentui benchmark

ALT BUN:FFI • REWRITTEN AS ENGINE-NATIVE FFI IN JAVASCRIPTCORE up to 3× faster ffi Symbols & callbacks are engine cells • hot call sites JIT to a bare call; ret • 70× less memory/ symbol 3.0x 3.3x O bun TinyccO bun •JSC-native 2.3x 1.4x TINYCC = 1x noop call 2.27 ns → 763 ps new CString( 99.5 → 30 ns yoga layout x1k opentui benchmark speedup vs previous TinyCC-based bun:ffi macOS arm64 • opentui: unmodified 347-symbol app scrollbox 10k opentui benchmark

12
11
524
144,585
Closed 911 issues as completed in the last 24 hrs. Many fixed in recent PRs. Some fixed long ago.
Closed | 911 https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aclosed%20closed%3A%3E2026-07-23%20reason%3Acompleted

ALT Closed | 911 https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aclosed%20closed%3A%3E2026-07-23%20reason%3Acompleted

21
8
621
37,867
"how does this compare"
Bun v1.4 starts 4.5x faster than Node.3.1x faster than Deno. Bun v1.4 4.8ms Deno 2.9.3 canary 14.9ms Node v26.5.0 22.0ms cold start • hello world • same file, same machine, same run console. log (123) • hyperfine, 300 runs × 3 rounds (median), pinned core • Linux x64, AMD EPYC 9R14 • bun = main @ b39a2704

ALT Bun v1.4 starts 4.5x faster than Node.3.1x faster than Deno. Bun v1.4 4.8ms Deno 2.9.3 canary 14.9ms Node v26.5.0 22.0ms cold start • hello world • same file, same machine, same run console. log (123) • hyperfine, 300 runs × 3 rounds (median), pinned core • Linux x64, AMD EPYC 9R14 • bun = main @ b39a2704

4
2
107
7,004
Bun v1.4 starts faster
Bun v1.4 starts faster than every other Bun. 4.8ms MS 20 COLD START • HELLO WORLD 1.3.14 •19.3ms startup regression — fixed in v1.4 10 fastest before v1.4 - 7.1ms V1.0 V1.1 V1.2 v1.3 4x faster than 1.3.14 • 1.5x faster than any Bun before it console. log (123) • hyperfine, 400 runs, pinned core • Linux x64, AMD EPYC 9R14 • v1.4 = main @ b39a2704 v1.4

ALT Bun v1.4 starts faster than every other Bun. 4.8ms MS 20 COLD START • HELLO WORLD 1.3.14 •19.3ms startup regression — fixed in v1.4 10 fastest before v1.4 - 7.1ms V1.0 V1.1 V1.2 v1.3 4x faster than 1.3.14 • 1.5x faster than any Bun before it console. log (123) • hyperfine, 400 runs, pinned core • Linux x64, AMD EPYC 9R14 • v1.4 = main @ b39a2704 v1.4

31
28
929
67,394
Bun v1.4 will be our biggest jump in Node.js compatibility since Bun v1.0
Line chart titled "Bun's Node.js test suite progress", subtitled "Official Node.js test suite files run on every commit". The line starts at 1,378 test files at Bun v1.2.0 (January 2025), climbs through the 1.2 series to 2,250 at v1.3.14, holds flat across the 1.3 releases, then spikes to 3,188 files on main today (July 2026). A dashed target line at 3,693 reads "The bar to ship Bun v1.4: 3,693", with "505 to go" marking the gap between main and the target.

ALT Line chart titled "Bun's Node.js test suite progress", subtitled "Official Node.js test suite files run on every commit". The line starts at 1,378 test files at Bun v1.2.0 (January 2025), climbs through the 1.2 series to 2,250 at v1.3.14, holds flat across the 1.3 releases, then spikes to 3,188 files on main today (July 2026). A dashed target line at 3,693 reads "The bar to ship Bun v1.4: 3,693", with "505 to go" marking the gap between main and the target.

36
32
1,060
226,911
In the next version of Bun Improved timer accuracy on Windows makes `Bun.sleep` faster
bun index.js - 1.55s bun-1.4 index.js - 142ms

ALT bun index.js - 1.55s bun-1.4 index.js - 142ms

27
13
799
477,385
Load more