- Express / Fastify / Hono / Koa
- Prisma 5+ (neuere Versionen unterstützen Bun offiziell)
- Zod / ts-pattern / effect-ts
- dotenv / nodemon (Buns integriertes `--hot` kann nodemon ersetzen) ### Erfordert Aufmerksamkeit
- **Native Module**: Einige auf node-gyp basierende Module lassen sich möglicherweise nicht bauen
- **cluster-Modul**: Unter Bun durch `Bun.spawn` ersetzen
- **worker_threads**: Teilweise unterstützt — komplexe Fälle prüfen ### Nicht unterstützt
- Einige OpenTelemetry-Plugins (Auto-Instrumentierung)
- Bestimmte interne Node-APIs (Teile von `v8`, `perf_hooks`) ## Migrationsschritte ### Schritt 1: Bun in CI parallel zu Node ausführen

Nutze lokal `bun run dev`. Die Produktion bleibt vorerst auf Node. ### Schritt 3: Bun in Staging deployen
Tausche das Docker-Image gegen `oven/bun:1.2` aus und beobachte das Verhalten mit einer Stichprobe echten Traffics. ### Schritt 4: Produktion umschalten
Wenn Arbeitsspeicher, CPU-Auslastung und Fehlerraten stabil bleiben, kann die Produktion umgestellt werden. ## Node vs Bun: Praxisnahe Benchmarks ### Mein API-Server-Fall (Express → Hono+Bun)
| Metrik | Node 22 + Express | Bun 1.2 + Hono |
|------|-------------------|----------------|
| Durchschnittliche Latenz | 45ms | 18ms |
| P99-Latenz | 120ms | 42ms |
| Speichernutzung | 380MB | 220MB |
| CPU (Durchschnitt) | 55% | 28% | ### Monorepo-Build
| Aufgabe | Node + Turbo | Bun (integriert) |
|------|-------------|-----------|
| install | 28s | 4s |
| build | 95s | 72s |
| test | 40s | 12s | ## Checkliste für das Produktions-Deployment - [ ] Alle Abhängigkeiten bauen und importieren sauber unter Bun
- [ ] Testsuite läuft zu 100% durch (Bun-Test-Runner oder dein bestehendes vitest-Setup)
- [ ] Speicherlecktest (24-stündiger Lastlauf)
- [ ] OpenTelemetry/APM-Integration verifiziert
- [ ] Docker-Image baut und deployt erfolgreich
- [ ] Rollback-Plan vorhanden (sofortiger Fallback auf Node) ## 💡 Praxiseinblick Viele Artikel übernehmen vor allem die Marketingaussage, Bun sei "3x schneller als Node". In der Praxis hängt der spürbare Unterschied jedoch stark von der jeweiligen Workload ab. In einem Cloudflare Pages + Next.js 15-Projekt, das ich betreibe (rund 50.000 monatliche Seitenaufrufe), dauerte `npm install` auf einem GitHub Actions Ubuntu-Runner im Schnitt 47 Sekunden. Mit `bun install` sank die Zeit auf 8–11 Sekunden, wodurch sich die gesamte CI-Laufzeit um etwa 76% verkürzte. Gleichzeitig führen native Module, die viele Entwickler in Korea einsetzen — `puppeteer`, `sharp`, `bcrypt` — unter Bun 1.2 nach Stand Mai 2026 noch vergleichsweise häufig zu Build-Fehlern. Enthält dein Stack also Bildverarbeitung oder Crawling-Pipelines, ist es sinnvoller, Node LTS parallel weiterzubetreiben. Ein weiterer praktischer Stolperstein sind Container-Basisimages: Koreanische Cloud-Anbieter wie NHN Cloud, NCP oder KT Cloud spiegeln das offizielle `oven/bun`-Image oft nicht. Ein direktes `FROM oven/bun:1.2` in einem Dockerfile aus einer koreanischen Region kann den Build dadurch im Schnitt um 40–60 Sekunden verlängern. Besser ist es, das Image vorab in einer internen Harbor-Registry zu cachen. Am Ende entscheidet häufig weniger die reine Runtime-Performance als der Kosteneffekt. Teams, deren Build-Zeiten abgerechnet werden, etwa bei Vercel oder Netlify, berichten nach dem Wechsel zu Bun regelmäßig von 20–30% niedrigeren monatlichen Build-Kosten. Genau dieser Infrastrukturkosten-Aspekt ist oft der stärkere Grund für die Migration. ## Fazit Bun 1.2 ist stabil genug, um bei überschaubaren API-Servern, CLI-Tools und CI/CD-Skripten sofort Nutzen zu bringen. Setups mit komplexen nativen Modulen oder strengen Enterprise-APM-Anforderungen fahren mit Node LTS weiterhin verlässlicher. Für Greenfield-Projekte ist Bun eine gute Wahl; bei bestehenden Projekten empfiehlt sich eine schrittweise Migration.