- Express / Fastify / Hono / Koa
- Prisma 5+ (recent versions officially support Bun)
- Zod / ts-pattern / effect-ts
- dotenv / nodemon (Bun's built-in `--hot` can replace nodemon) ### Needs attention
- **Native modules**: Some node-gyp-based modules may fail to build
- **cluster module**: Replace with `Bun.spawn` on Bun
- **worker_threads**: Partially supported — verify complex cases ### Not supported
- Some OpenTelemetry plugins (auto-instrumentation)
- Certain Node internal APIs (parts of `v8`, `perf_hooks`) ## Migration Steps ### Step 1: Run Bun alongside Node in CI

Use `bun run dev` locally. Keep production on Node for now. ### Step 3: Deploy Bun to staging
Swap the Docker image for `oven/bun:1.2`. Monitor it against a sample of real traffic. ### Step 4: Cut over production
Once memory, CPU, and error rates look stable, complete the production cutover. ## Node vs Bun: Real-World Benchmarks ### My API server case (Express → Hono+Bun)
| Metric | Node 22 + Express | Bun 1.2 + Hono |
|------|-------------------|----------------|
| Average latency | 45ms | 18ms |
| P99 latency | 120ms | 42ms |
| Memory usage | 380MB | 220MB |
| CPU (avg) | 55% | 28% | ### Monorepo build
| Task | Node + Turbo | Bun (built-in) |
|------|-------------|-----------|
| install | 28s | 4s |
| build | 95s | 72s |
| test | 40s | 12s | ## Production Deployment Checklist - [ ] All dependencies build and import cleanly under Bun
- [ ] Test suite passes 100% (Bun test runner or your existing vitest setup)
- [ ] Memory leak test (24-hour load run)
- [ ] OpenTelemetry/APM integration verified
- [ ] Docker image builds and deploys successfully
- [ ] Rollback plan in place (instant fallback to Node) ## 💡 Real-World Insight Many articles repeat the marketing claim that "Bun is 3x faster than Node," but the real-world difference depends heavily on the workload. In one Cloudflare Pages + Next.js 15 project I run, with around 50,000 monthly page views, `npm install` averaged 47 seconds on a GitHub Actions Ubuntu runner. After switching to `bun install`, that dropped to 8–11 seconds, reducing CI time by roughly 76%. Still, native modules that Korean developers often rely on — `puppeteer`, `sharp`, and `bcrypt` — can still fail to build on Bun 1.2 fairly often as of May 2026. If your stack includes image processing or crawling pipelines, keeping Node LTS running in parallel is the safer option. There is also a deployment wrinkle: container base images on Korean cloud providers such as NHN Cloud, NCP, and KT Cloud often do not mirror the official `oven/bun` image. Pulling `FROM oven/bun:1.2` directly from a Korean region can add 40–60 seconds of latency on average, so pre-caching the image in an internal Harbor registry is a better setup. In many migrations, cost ends up being the deciding factor. Teams on metered build-time platforms such as Vercel or Netlify often report 20–30% lower monthly build costs after moving to Bun, which can make infrastructure savings a stronger reason to migrate than runtime speed alone. ## Wrapping Up Bun 1.2 is mature enough to produce quick wins for straightforward API servers, CLI tools, and CI/CD scripts. Projects that rely on complex native modules or enterprise-grade APM are still better served by Node LTS for now. For greenfield work, Bun is a strong default; for existing systems, a phased migration remains the safest path.