Bun in 2026: everything that changed since 1.0 and what actually breaks

Bun is no longer just a faster Node. It ships its own Postgres, Redis, MySQL, and S3 clients. It has a frontend dev server. It runs HTTP/3. Anthropic acquired it in December 2025. The migration question has gotten more interesting than any major version bump.

Here is the honest answer: Bun wins for greenfield serverless, CLI tooling, and monorepo install loops. For existing production services, the calculus depends on how much test coverage you have and whether you hit any of the six known gotchas documented below.

Who this is for

Engineers weighing whether to adopt or migrate to Bun in 2026. If you are still on Bun 1.0 or 1.1 from two years ago, you are running a materially different product — most of the built-in clients did not exist yet.

Skip ahead to What actually breaks if you already know Bun’s backstory.

What changed between 1.0 and 1.3.14

Bun 1.2 (January 2025)

This was the release that shifted Bun from “fast Node alternative” to “full-stack runtime.”

Native Postgres client: import { sql } from "bun" with parameterized queries, no driver install required. The client targets latency — connection setup is done in native code and re-used across requests.
Native S3 client: import { s3 } from "bun", then s3.file("folder/key") for streaming reads and writes. The file interface mirrors Bun.file() so the mental model transfers.
CSS bundler: Bun.build() now handles .css alongside JS/TS. One bundler for the whole app.
HTTP/2 server: added in 1.2.
Bytecode caching: the runtime now caches compiled bytecode to disk, cutting repeat cold starts.
Text lockfile: bun.lock is now human-readable plain text. Diffs in PRs are finally useful.

Bun 1.3 (October 2025)

Frontend dev server: HMR, asset serving, and TypeScript compilation — start it by passing an HTML entry point directly to bun. The target user is anyone currently running webpack-dev-server or Vite in development — not a replacement for production bundlers, but a faster inner loop.
Native MySQL client: joins Postgres and SQLite (already native) to complete the relational trifecta.
Native Redis client: import { redis } from "bun" with pipeline and pub/sub support.
Parameterized routes: Bun.serve({ routes: { "/user/:id": handler } }) — no routing library needed for simple services.
Node.js compatibility: 800+ additional passing tests in the Node.js test suite. The compatibility surface is meaningfully wider.

Bun 1.3.14 (May 2026)

HTTP/2 client (experimental): fetch() gains HTTP/2 support, but it is experimental and requires explicit opt-in — CLI flag --experimental-http2-fetch, env var BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP2_CLIENT=1, or per-request option fetch(url, { protocol: "http2" }). Not enabled by default.
Bun.Image: a native image processing API (resize, convert, encode/decode). First-class replacement for sharp in many cases.
7× faster warm installs: the package manager re-uses its local cache more aggressively when [install] globalStore = true is set in bunfig.toml (off by default). On a ~1,400-package fixture measured with hyperfine --warmup 3 --runs 10, warm install time dropped from 841ms to ~115ms (~7×).

The Anthropic acquisition (December 2025)

Jarred Sumner announced Bun joining Anthropic in December 2025. The stated terms: stays MIT-licensed, same team, Anthropic provides infrastructure and capital. The practical effect: CI got faster, the release cadence accelerated, and the native client library work (Postgres, Redis, MySQL, S3, HTTP/3) picked up pace.

For production-adoption purposes, this resolves the “what happens to the single-vendor OSS project if funding dries up?” risk. It introduces a different question: Anthropic is an AI company, not a developer-tools company. The roadmap alignment may drift over a two-year horizon.

Performance: what the numbers actually mean

Benchmark claims about Bun require a methodology note because the synthetic-versus-production gap is real and large.

Where Bun wins clearly

Workload	Bun	Node	Notes
`bun install` (cold, 500 packages)	~3s	~75s (npm)	25× faster
`bun install` (warm cache, 1.3.14, `globalStore=true`)	~115ms	—	~7× faster than pre-1.3.14
Lambda cold start (minimal HTTP server)	~290ms	~940ms	69% faster
Test runner (TypeScript test suite, no build)	~2–5× faster	baseline	Build step skipped
Script startup	8–15ms	60–120ms	Per-process overhead

The Lambda cold start is the strongest production case. For functions invoked infrequently, 290ms vs 940ms is a user-visible difference.

Package install speed is real and composites over a team day. If you run bun install twenty times across a dev day, you recover minutes, not seconds.

Where the gap closes

HTTP throughput on synthetic benchmarks shows 2.8× improvement for Bun. HTTP throughput on real-world CRUD services — where most time is spent waiting for the database — shows roughly a 3% improvement. The 2.8× number is a UV loop throughput measurement, not an end-to-end application measurement.

This is not a Bun problem specifically. It is how runtime benchmarks always work. Know which one you are reading.

What actually breaks

Six migration gotchas from primary sources, in order of how often they bite:

1. `experimentalDecorators` behavior changed in a patch release

A 1.2.x patch release changed how experimentalDecorators works when combined with useDefineForClassFields. If you use decorators (NestJS, TypeORM, Angular), pin your Bun version in CI and test explicitly on upgrades.

Fix: lock BUNVERSION=1.x.y in your CI image. Do not pin to latest.

2. Native addons that target Node ABI directly can segfault

better-sqlite3 and several PDF-processing libraries target the Node C++ ABI and expect Node’s V8 embedding layout. Bun uses JavaScriptCore, and the compatibility shim does not cover all native addon patterns. The failure mode is a segfault, not an error.

Fix: replace better-sqlite3 with Bun’s built-in SQLite (import { Database } from "bun:sqlite"). For other native addons, check the Bun Node compatibility tracker before migrating.

3. `.env` auto-loading priority differs from dotenv

Bun auto-loads .env files without dotenv. The priority order is different: .env.local takes precedence over .env, and there is no NODE_ENV-specific .env.production loading by default. If your app relied on dotenv’s load order, behavior changes on migration.

Fix: explicitly set --env-file or verify your .env structure against Bun’s documented load order.

4. Jest compatibility — not a drop-in

One documented real-world migration (dev.to) required rewriting 60 of 420 tests when switching from Jest to bun test. Mocking APIs differ. Timer mocks differ. Module mocking with jest.mock() does not exist.

Fix: budget rewrite time for your test suite before committing to migration. Run bun test against your existing Jest tests first — the failures surface the gap.

5. `dirname` and `filename` in ESM

In Node ESM ("type": "module"), __dirname and __filename are not defined. Bun defines them anyway for ergonomic reasons, which means code that works in Bun ESM may not work in Node ESM. If you ship libraries, this is a portability bug.

Fix: use import.meta.dirname and import.meta.filename instead. They work in both runtimes.

6. `node:crypto` `createCipheriv` subtle differences

Bun’s implementation of node:crypto passes most compatibility tests, but there are documented edge cases in createCipheriv and related streaming cipher APIs. If your code uses these directly (not via a library abstraction), test explicitly.

Fix: run your crypto-using code against Bun’s test suite. If you are using a library like jose or jsonwebtoken, these are already tested against Bun and generally safe.

Verdict

Use Bun for:

Greenfield serverless functions — the Lambda cold start improvement alone justifies it
Internal tooling and CLIs — startup speed, TypeScript out of the box, no extra toolchain
Monorepos — install speed and workspace support are genuinely better
New services where you want built-in Postgres/Redis/MySQL without driver packages

Be careful with Bun if:

You have a production service with heavy native addon usage (check your node_modules for native .node files before migrating)
You have a large Jest test suite with extensive mocking — budget for the rewrite
Your organization needs an explicit LTS contract (Bun has no LTS policy as of May 2026)

The Anthropic acquisition question:

For most developers: neutral to positive. The project is better-funded, MIT license is confirmed, same team. The longer-term roadmap alignment risk is real but speculative.

For enterprises: the change from independent OSS project to Anthropic subsidiary is worth noting in your vendor assessment, but it is not a blocker — Anthropic is not going anywhere.

Caveats

The benchmark numbers in this article come from primary sources (bun.sh blog posts and community reproduction). toolchew has not run independent performance measurements — the numbers are well-corroborated across independent reporters.

The six gotchas come from GitHub Issues, community posts, and migration write-ups. They represent documented, reproducible failures — not theoretical concerns.

This article contains an affiliate link to Cloudflare Workers. toolchew independently uses and recommends Cloudflare Workers for Bun deployments. The affiliate relationship did not influence the verdict.

Deploy your Bun app

Bun on Cloudflare Workers gives you the fastest cold starts in the platform (Workers already had low cold starts; Bun’s startup overhead narrows the gap further). Workers’ pricing model — 100K requests/day free, then $0.50 per million — works well for the “lots of small functions” pattern Bun enables.

Deploy your Bun app on Cloudflare Workers →

Vercel also supports Bun runtime via the bun runtime flag in vercel.json. Worth noting if you are already on the Vercel platform.