Bun 1.2 stops being a runtime and starts being a platform

Bun 1.2 landed this week and the release is a good moment to notice what the project has actually become. It started as "a fast JavaScript runtime." It is now attempting to be the entire server-side JavaScript toolchain in one binary, and the 1.2 feature list is unsubtle about it.

what's new#

A built-in S3 client. Bun.s3 gives you presigned URLs, streaming reads and writes, and it works against any S3-compatible endpoint — R2, MinIO, Backblaze, the actual thing.

import { s3 } from "bun";

const file = s3.file("uploads/report.pdf");
await file.write(pdfBytes, { type: "application/pdf" });
const url = file.presign({ expiresIn: 3600 });

A built-in Postgres client. Bun.sql is a tagged-template SQL interface with connection pooling, prepared statements, and parameter binding that does not require you to think about $1 ordering.

import { sql } from "bun";
const users = await sql`select * from users where team = ${teamId} limit 20`;

Node compatibility as a first-class metric. Bun now publishes its pass rate against Node's own test suite and treats regressions as bugs. That is a much more honest signal than a feature checklist, and the number went up substantially in this cycle.

Text-based lockfile. bun.lock replaces the binary bun.lockb as the default. Reviewable in a pull request, diffable, mergeable. This was the single most common complaint about adopting Bun in a team setting and it is now gone.

the strategic read#

Node's answer to the same problem has been to add capabilities to the runtime incrementally and carefully: a built-in test runner, --watch, a permission model, and now stable-ish TypeScript stripping. Deno's answer was to bundle everything from the start and then spend years walking back the parts of its opinionated design that made adoption hard.

Bun's answer is to bundle everything and be compatible with Node's ecosystem rather than replacing it. That is a harder engineering problem and a much easier sales problem. Nobody has to rewrite anything. You point bun at an existing Express app and it mostly runs.

the honest caveats#

Bun's ecosystem edge cases still bite. Native modules that assume V8 internals will not work, because Bun is JavaScriptCore. Some observability agents assume Node. Long-tail packages that reach into process.binding or undocumented internals will surprise you.

The pattern for adoption in 2025 looks like: use Bun as the package manager and test runner immediately, because those are drop-in and dramatically faster; use the runtime in production when your dependency tree is one you actually understand.

That is not a hedge. That is just what shipping looks like.