Bun 1.2 in production · what we keep, what we skip

Every six months someone asks if Bun is production-ready. For two years the honest answer was: mostly, with caveats that bite. In Q1 2026, with Bun 1.2, we finally flipped six SaaS backends over and kept them there. This is what the work actually looked like.

Why we bothered at all

• Cold start halved on Lambda / Cloud Run · p50 went from 420ms to 210ms on a typical Hono app.
• RSS at steady state down 20-30% · translates to ~$200/mo saved on a 6-node fleet.
• Build tooling disappeared · no tsc, no esbuild, no tsup, no ts-node. The runtime reads .ts directly.
• bun install is 10-25x faster than npm · local dev turnaround stops being a papercut.

What still breaks

Bun 1.2 is close to Node-API parity but not at it. Three issues cost us real time in 2026 migrations.

• Native modules with custom C++ addons · we had to swap a scrypt implementation and one TLS certificate parser.
• AWS SDK v3 streams · specific edge case with S3 multipart upload under Bun's fetch. Fixed in 1.2.3 but we pin.
• APM agents · Datadog and New Relic agents still expect Node internals; use OpenTelemetry + OTLP instead.

What we ship on Bun today

1. HTTP APIs (Hono, Elysia, raw Bun.serve) · always · this is where Bun wins biggest.
2. Background workers consuming SQS / Redis · yes · cold start helps batch jobs.
3. Next.js on Bun · yes for bun install + bun run, but next build still goes through Node for some plugin ecosystems.
4. CLI tools · yes · bun build --compile ships a single binary.

What we still run on Node

• Anything with a Datadog APM agent contract we cannot renegotiate.
• Services leaning hard on worker_threads pools · Bun has them but the semantics differ subtly.
• Legacy services with > 3 native deps we have not audited · the audit is 2 days we will not spend on low-traffic services.

The cutover checklist

Every migration follows the same five steps. We have not had a rollback to Node in the last four cutovers, but the rollback path stays warm for two weeks after.