- Express / Fastify / Hono / Koa
- Prisma 5+ (las versiones recientes admiten Bun oficialmente)
- Zod / ts-pattern / effect-ts
- dotenv / nodemon (el `--hot` integrado de Bun puede reemplazar a nodemon) ### Requiere atención
- **Módulos nativos**: Algunos módulos basados en node-gyp pueden fallar al compilar
- **Módulo cluster**: Sustitúyelo por `Bun.spawn` en Bun
- **worker_threads**: Soporte parcial; conviene validar los casos complejos ### No soportado
- Algunos plugins de OpenTelemetry (autoinstrumentación)
- Ciertas API internas de Node (partes de `v8`, `perf_hooks`) ## Pasos de migración ### Paso 1: Ejecuta Bun junto a Node en CI

Empieza usando `bun run dev` en local. Deja producción en Node por el momento. ### Paso 3: Despliega Bun en staging
Cambia la imagen Docker a `oven/bun:1.2` y monitoriza el comportamiento con una muestra de tráfico real. ### Paso 4: Pasa producción
Cuando hayas revisado memoria, CPU y tasas de error, completa el cambio. ## Node vs Bun: benchmarks reales ### Mi caso de servidor API (Express → Hono+Bun)
| Métrica | Node 22 + Express | Bun 1.2 + Hono |
|------|-------------------|----------------|
| Latencia media | 45ms | 18ms |
| Latencia P99 | 120ms | 42ms |
| Uso de memoria | 380MB | 220MB |
| CPU (media) | 55% | 28% | ### Build de monorepo
| Tarea | Node + Turbo | Bun (integrado) |
|------|-------------|-----------|
| install | 28s | 4s |
| build | 95s | 72s |
| test | 40s | 12s | ## Checklist de despliegue en producción - [ ] Todas las dependencias compilan e importan correctamente con Bun
- [ ] La suite de pruebas pasa al 100% (test runner de Bun o tu configuración actual de vitest)
- [ ] Prueba de fugas de memoria (ejecución de carga durante 24 horas)
- [ ] Integración de OpenTelemetry/APM verificada
- [ ] La imagen Docker se construye y despliega correctamente
- [ ] Plan de rollback preparado (vuelta instantánea a Node) ## 💡 Aprendizaje real Muchos blogs repiten el mensaje de marketing de que "Bun es 3 veces más rápido que Node", pero en producción la mejora se nota más o menos según el tipo de carga. En un proyecto de Cloudflare Pages + Next.js 15 que mantengo (alrededor de 50.000 visitas de página mensuales), `npm install` tardaba una media de 47 segundos en un runner Ubuntu de GitHub Actions; al pasar a `bun install`, el tiempo bajó a 8-11 segundos, lo que recortó la CI en aproximadamente un 76%. Aun así, los módulos nativos que muchos equipos coreanos utilizan a diario — `puppeteer`, `sharp`, `bcrypt` — todavía provocan fallos de compilación en Bun 1.2 con bastante frecuencia a fecha de mayo de 2026. Si tu stack incluye procesamiento de imágenes o pipelines de crawling, lo prudente es mantener Node LTS en paralelo. Hay otro detalle operativo: las imágenes base de contenedor en proveedores cloud coreanos (NHN Cloud, NCP, KT Cloud) a menudo no replican la imagen oficial `oven/bun`, así que usar `FROM oven/bun:1.2` directamente en un Dockerfile desde una región coreana añade de media entre 40 y 60 segundos de latencia; en ese caso, conviene precachearla en un registro Harbor interno. Al final, el factor que más pesa suele ser el coste: los equipos con planes donde el tiempo de build se factura, como Vercel o Netlify, suelen ver reducciones del 20-30% en el gasto mensual de build después de migrar a Bun. Por eso, muchas veces el argumento económico acaba siendo más convincente que el rendimiento bruto por sí solo. ## Cierre Bun 1.2 ya es lo bastante estable como para aportar mejoras inmediatas en servidores API sencillos, herramientas CLI y scripts de CI/CD. En cambio, los entornos que dependen de módulos nativos complejos o necesitan APM de nivel empresarial siguen estando más seguros sobre Node LTS. Para proyectos nuevos, Bun es una opción razonable; para proyectos existentes, lo más sensato es migrar por fases.