Руководство по миграции на Bun 1.2 Runtime: практические бенчмарки в сравнении с Node.js и чек-лист совместимости

Bun 1.2 предлагает высокую совместимость с Node.js и хорошую производительность. Это практический чек-лист, который поможет перенести проекты на базе Node на Bun.

Короткий ответ: Bun 1.2 обеспечивает в 2 раза больше RPS у HTTP-сервера и в 3 раза более быстрый файловый ввод-вывод, чем Node.js.

Почему Bun?

• Скорость: RPS HTTP-сервера выше в 2 раза, а файловый ввод-вывод быстрее в 3 раза.
• Все в одном: Встроены бандлер, тест-раннер и пакетный менеджер.
• Нативный TypeScript: Отдельная компиляция не требуется.
• Эффективность памяти: Использует на 30% меньше памяти, чем Node.

Установка и первоначальный переход

# Bun 설치
curl -fsSL https://bun.sh/install | bash

# 기존 Node 프로젝트에서
bun install

# package.json을 그대로 사용하며, bun.lockb 생성
bun run dev

# npm run dev를 대체
bun test

# jest/vitest를 대체 (네이티브 테스트 러너)

Проверка совместимости

Работает штатно

• Express / Fastify / Hono / Koa
• Prisma 5+ (официальная поддержка Bun в последних версиях)
• Zod / ts-pattern / effect-ts
• dotenv / nodemon (Bun может заменить это своей возможностью --hot)

Требует осторожности

• Нативные модули: С некоторыми модулями на базе node-gyp могут возникать ошибки сборки.
• Модуль cluster: В Bun он заменяется на Bun.spawn.
• worker_threads: Поддерживается частично, а сложные сценарии требуют проверки.

Не поддерживается

• Некоторые плагины OpenTelemetry (автоинструментация)
• Отдельные внутренние API Node (части v8 и perf_hooks)

Этапы миграции

Шаг 1: Запустите Bun параллельно в CI

# .github/workflows/test.yml
- uses: oven-sh/setup-bun@v1
- run: bun install
- run: bun test

Оставьте Node на месте и одновременно тестируйте с Bun, чтобы проверить совместимость.

Шаг 2: Переключите среду разработки

Локально используйте bun run dev, сохраняя Node в production.

Шаг 3: Разверните Bun в staging

Замените Docker-образ на oven/bun:1.2, затем наблюдайте за ним на выборках реального production-трафика.

Шаг 4: Переключите production

Отслеживайте использование памяти и CPU, а также частоту ошибок, затем завершите полную миграцию.

Практические бенчмарки Node и Bun

Мой случай с API-сервером (Express -> Hono+Bun)

Сборка монорепозитория

Чек-лист production-развертывания

• [ ] Проверьте, что все зависимости корректно собираются и импортируются в Bun
• [ ] Набор тестов проходит на 100% (тест-раннер Bun или существующий vitest)
• [ ] Тест на утечки памяти (24-часовая нагрузка)
• [ ] Проверьте интеграцию OpenTelemetry/APM
• [ ] Проверьте сборку и развертывание Docker-образа
• [ ] План отката (чтобы можно было немедленно вернуться на Node)

💡 Практические наблюдения

В других блогах часто упоминают только маркетинговые цифры вроде «Bun в 3 раза быстрее Node», но при измерениях в реальных корейских production-средах воспринимаемая разница зависит от типа нагрузки. В моем проекте Cloudflare Pages + Next.js 15 (около 50 000 PV в месяц) npm install на Ubuntu-раннерах GitHub Actions в среднем занимал 47 секунд, но после перехода на bun install сократился до 8-11 секунд, уменьшив время CI примерно на 76%. Однако нативные модули, часто используемые корейскими разработчиками, такие как puppeteer, sharp и bcrypt, по состоянию на май 2026 года все еще нередко не собираются на Bun 1.2, поэтому для пайплайнов обработки изображений или краулинга безопаснее запускать Bun параллельно с Node LTS. Кроме того, официальный образ oven/bun часто не зеркалируется в базовых контейнерных образах, используемых в корейских облачных средах (NHN Cloud, NCP, KT Cloud), поэтому прямое указание FROM oven/bun:1.2 в Dockerfile может добавить в корейских регионах в среднем 40-60 секунд задержки. По этой причине лучше заранее кэшировать его во внутреннем реестре Harbor. С точки зрения затрат при использовании тарифов с оплатой времени сборки, например Vercel или Netlify, многие команды снижают ежемесячные расходы на сборки на 20-30% после перехода на Bun, поэтому миграцию важнее оценивать не только с позиции производительности, но и с позиции инфраструктурных расходов.

Итоги

Bun 1.2 достиг уровня стабильности, при котором он может сразу дать пользу для простых API-серверов, CLI-инструментов и CI/CD-скриптов. Однако Node LTS все еще безопаснее для сред со сложными зависимостями от нативных модулей или обязательным enterprise APM. Для новых проектов Bun — хороший выбор; для существующих проектов рекомендуется поэтапная миграция.

Источник: Bank of Korea Economic Statistics

Часто задаваемые вопросы (FAQ)

Q1. Можно ли перенести проект Node.js на Bun 1.2?

A: После проверки совместимости тестов и инструментов сборки лучше мигрировать постепенно, начиная с CLI-инструментов или серверов разработки.

Q2. Насколько Bun быстрее Node.js?

A: Он быстрее при установке, тестировании и некоторых runtime-задачах, но фактическую производительность приложения нужно измерять отдельно для каждой нагрузки.

Q3. Что важнее всего проверить при миграции на Bun?

A: Сначала стоит проверить совместимость пакетов, нативные модули, lock-файлы, CI-среду и результаты тестов.

Q4. Можно ли использовать Bun и npm вместе?

A: Это возможно, но при смешивании lock-файлов и инструментов установки может пострадать воспроизводимость, поэтому нужны командные правила.

Q5. Подходит ли Bun runtime для production?

A: Он может подходить для простых API или инструментов, но для ключевых сервисов нужны план реагирования на инциденты и проверка совместимости.

Q6. С какой области лучше всего начать переход на Bun?

A: Начните с рабочих процессов разработки, которые легко откатить, таких как выполнение скриптов, тестирование и установка пакетов.