Як налаштувати Bun.js сервер із Fastify: від нуля до продакшену
Практичний посібник зі створення сервера на Bun.js із Fastify, готового до продакшену. Встановіть Bun, створіть HTTP-сервер, додайте маршрути TypeScript, обробіть валідацію, підключіть базу даних і розгорніть — із бенчмарками, що показують різницю продуктивності між Bun + Fastify та Node.js + Fastify.
Посібник з налаштування Bun сервера 2026
Двочастинний посібник зі створення продакшен-готових серверів на Bun. Частина 1 охоплює основи рантайму Bun та налаштування Fastify. Частина 2 — NestJS на Bun та оптимізацію продуктивності.
Усі статті в цьому гайді
01
Bun.js сервер із Fastify: від нуля до продакшену
Встановіть Bun, створіть HTTP-сервер, додайте маршрути TypeScript з Fastify, обробіть валідацію, підключіть базу даних та розгорніть з Docker.
02
NestJS на Bun.js: налаштування та оптимізація продуктивності
Запустіть NestJS на Bun, налаштуйте SWC, увімкніть модулі ледачого завантаження, переключіться на адаптер Fastify та застосуйте оптимізації продуктивності.
Висновок
Це практичний посібник від нуля до працюючого сервера. Попередній досвід з Bun не потрібен.
Bun.serve() ( нативний) та fastify.listen() (фреймворк)bun:sqlite)Якщо ви створювали сервери на Node.js, більшість ваших знань переноситься безпосередньо. Найважливіші відмінності — архітектура рушія, вбудовані інструменти та обробка TypeScript.
| Comparison point | Bun 1.3 | Node.js 22/23 |
|---|---|---|
| JavaScript engine | JavaScriptCore (Safari/WebKit) | V8 (Chrome/Chromium) |
| Written in | Zig + C++ | C++ + JavaScript |
| TypeScript | Native (zero config, no transpile step) [1] | Experimental via --experimental-strip-types (Node 23) [2] |
| Package manager | Built-in (bun install) — 10-30x faster than npm [1] | npm, yarn, pnpm (external) |
| Bundler | Built-in (bun build) — Webpack-class features [1] | None built-in (requires Webpack, Vite, esbuild) |
| Test runner | Built-in (bun test) — Jest-compatible, ~20x faster [1] | Built-in node:test (basic, stable since v20) [2] |
| Cold start | 8-15ms | 40-120ms |
| HTTP throughput (Fastify) | ~95,200 req/s [3] | ~55,800 req/s [3] |
| Memory baseline | ~380MB | ~512MB |
| npm compatibility | ~98% of top 1000 packages | 100% (native) |
Підсумок
Для нових серверних проєктів Bun пропонує швидший рантайм, простіший набір інструментів та нативний TypeScript. Решта 2% npm-несумісності зосереджені в нативних C++ додатках на кшталт bcrypt чи node-sass — більшість веб-фреймворків та ORM працюють без змін.
Bun встановлюється як один бінарний файл. Node.js, npm чи окремі інструменти збірки не потрібні.
Встановіть через curl
curl -fsSL https://bun.sh/install | bashThis downloads the Bun binary, adds it to your PATH, and verifies the installation. After installation, run bun --version to confirm.
Встановіть через PowerShell
powershell -c "irm bun.sh/install.ps1|iex"Windows support reached stable status in Bun 1.3. All core features — runtime, package manager, test runner, and bundler — work on Windows. [1]
Підтвердьте встановлення
bun --versionВи маєте побачити 1.3.x або новіше. Bun готовий до роботи. Окреме встановлення Node.js для проєктів Bun не потрібне, хоча наявність Node.js поруч з Bun є поширеною практикою і працює без конфліктів.
Створіть директорію проєкту, встановіть Fastify та напишіть перший серверний файл — усе на TypeScript, без кроку збірки.
Створіть проєкт та встановіть залежності
mkdir my-bun-server && cd my-bun-server
bun init
bun add fastifybun init створює мінімальний package.json з "type": "module". bun add fastify встановлює Fastify з npm — менеджер пакетів Bun завантажує та розрішує залежності на 10-30x швидше за npm. [1]
Створіть точку входу сервера
// server.ts
import Fastify from "fastify";
const fastify = Fastify({ logger: true });
fastify.get("/", async (request, reply) => {
return { hello: "world", runtime: "bun" };
});
fastify.get("/health", async (request, reply) => {
return { status: "ok", uptime: process.uptime() };
});
const start = async () => {
try {
await fastify.listen({ port: 3000, host: "0.0.0.0" });
console.log("Server running at http://localhost:3000");
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();Це стандартний код Fastify. Єдина відмінність від Node.js: ви запускаєте його bun замість node, а розширення .ts працює безпосередньо.
Запустіть сервер
bun run server.tsThat is it. No tsc, no ts-node, no nodemon, no build step. Bun reads the TypeScript file, strips types at parse time, and executes it. For development with hot reload, use bun --hot server.ts — Bun preserves application state across reloads, which is faster than Node.js's --watch flag that restarts the entire process. [1]
Що щойно відбулося
Ви створили працюючий сервер Fastify на TypeScript двома командами (bun init та bun add fastify) та одним файлом (server.ts). Без конфігураційних файлів, інструментів збірки чи кроку транспіляції. Це ключова різниця в DX між Bun та Node.js.
Bun надає два способи створення HTTP-серверів: нативний API Bun.serve() та сторонні фреймворки на кшталт Fastify. Обидва працюють на рантаймі Bun, але задовольняють різні потреби.
Bun.serve() — це вбудований HTTP-сервер Bun. Це найшвидший варіант — бенчмарки показують приблизно 180 000 запитів/сек для plaintext-відповідей порівняно з 65 000 запитів/сек у Node.js. Він ідеальний для простих API, мікросервісів та критичних до продуктивності кінцевих точок з мінімальними накладними витратами. [1][3]
Fastify додає структурований поверх: валідацію JSON Schema, оптимізацію серіалізації, архітектуру плагінів, хуки та декоратори. Запуск Fastify на Bun дає ~95 200 запитів/сек порівняно з ~55 800 запитів/сек на Node.js — приблизно на 70% більшу пропускну здатність. Ви втрачаєте частину сирої швидкості порівняно з Bun.serve(), але отримуєте фреймворк продакшен-рівня з валідацією, обробкою помилок та розширюваністю. [3]
Для більшості реальних застосунків Fastify на Bun — прагматичний вибір. Накладні витрати фреймворку — це частка загального часу запиту, коли ви додаєте запити до бази даних, автентифікацію та бізнес-логіку. Сама валідація схем — яку Fastify обробляє на рівні фреймворку з прискоренням серіалізації в 2-3 рази — часто виправдовує цей вибір. [4][5]
Використовуйте Bun.serve() коли
Вам потрібна максимальна сирої пропускна здатність для простих кінцевих точок. Створюєте легковаговий проксі, сервіс перевірки здоров'я, приймач вебхуків або внутрішній мікросервіс. Вам потрібен найменший холодний старт для serverless-розгортань. Ви готові самостійно обробляти маршрутизацію, валідацію та обробку помилок.
Використовуйте Fastify на Bun коли
Вам потрібна валідація JSON Schema та серіалізація. Ви хочете екосистему плагінів (CORS, автентифікація, Swagger, rate limiting). Створюєте REST або GraphQL API з кількома маршрутами. Вам потрібна структурована обробка помилок та хуки життєвого циклу запиту. Вам потрібні інструменти розробника продакшен-рівня.
Уникайте Bun.serve() коли
Ваш API має складні вимоги до валідації. Вам потрібна генерація документації OpenAPI/Swagger. Ви покладаєтеся на специфічні для фреймворку плагіни. Ваша команда очікує патернів Express/Fastify для підтримки.
Bun.serve() забезпечує найвищу сирою пропускну здатність, але Fastify на Bun забезпечує сильний баланс функцій фреймворку та продуктивності. Реальна різниця між Fastify на Bun та Fastify на Node.js становить приблизно 70%.
Скріншот секції bun-serve-vs-fastifyСила Fastify — структурована валідація запитів за допомогою JSON Schema. Ось як створити валідовані маршрути на Bun.
Створіть модуль валідованого маршруту
// routes/users.ts
import { FastifyPluginAsync } from "fastify";
export const userRoutes: FastifyPluginAsync = async (fastify) => {
const createUserBody = {
type: "object",
required: ["email", "name"],
properties: {
email: { type: "string", format: "email" },
name: { type: "string", minLength: 1, maxLength: 100 },
role: { type: "string", enum: ["admin", "user", "viewer"] },
},
} as const;
fastify.post("/users", {
schema: { body: createUserBody },
}, async (request, reply) => {
const { email, name, role } = request.body;
return {
id: crypto.randomUUID(),
email,
name,
role: role ?? "user",
createdAt: new Date().toISOString(),
};
});
fastify.get("/users/:id", {
schema: {
params: {
type: "object",
properties: { id: { type: "string" } },
required: ["id"],
},
},
}, async (request, reply) => {
const { id } = request.params as { id: string };
return { id, message: "User lookup placeholder" };
});
};Зареєструйте маршрути в головному файлі сервера
// server.ts
import Fastify from "fastify";
import { userRoutes } from "./routes/users";
const fastify = Fastify({ logger: true });
fastify.register(userRoutes);
fastify.setErrorHandler((error, request, reply) => {
if (error.validation) {
reply.status(400).send({
error: "Validation failed",
details: error.validation,
});
return;
}
fastify.log.error(error);
reply.status(500).send({ error: "Internal server error" });
});
const start = async () => {
try {
await fastify.listen({ port: 3000, host: "0.0.0.0" });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();Run with bun run server.ts. Invalid request bodies now return structured 400 errors automatically.
Ключовий момент
Валідація схем Fastify працює однаково на Bun та Node.js. Єдина відмінність — валідований обробник виконується швидше на рантаймі Bun. Якщо ваші існуючі маршрути Fastify використовують JSON Schema, вони працюватимуть на Bun без змін.
Bun підтримує два шляхи роботи з базами даних: вбудований модуль bun:sqlite для легкого локального зберігання та стандартні драйвери npm для PostgreSQL, MySQL, MongoDB та інших баз даних. Для PostgreSQL драйвер pg працює на Bun без змін. [1]
Для рівня ORM, Prisma, Drizzle ORM та TypeORM працюють на Bun. Prisma зокрема добре перевірений — команда Prisma підтвердила сумісність з Bun та багато продакшен-розгортань використовують Prisma + Bun + PostgreSQL. [1][2]
Вбудований модуль SQLite Bun (bun:sqlite) корисний для прототипування, кешування та single-instance розгортань, де зовнішня база даних є зайвою. Для продакшен-API, PostgreSQL через pg або ORM на кшталт Prisma є стандартним вибором.
Практична порада
Використовуйте bun:sqlite для прототипування та single-instance кешування. Використовуйте PostgreSQL + Prisma або Drizzle для продакшен-API. Обидва працюють на Bun без змін конфігурації, окрім рядка підключення до бази даних.
Вбудований тест-раннер Bun використовує Jest-сумісні API. Більшість існуючих тестових файлів працюють без змін.
Напишіть тест маршруту
Create a test file using Bun's built-in test runner. Import describe, it, and expect from bun:test. The API is Jest-compatible so existing NestJS/Fastify tests migrate with minimal changes. Use app.inject() to test routes without starting a real HTTP server. Run all tests with bun test, which discovers files matching *.test.ts and *.spec.ts automatically. A test suite of 500 tests completes in approximately 1.2 seconds compared to Jest 24 seconds. [1]
Примітка про міграцію
Якщо ваш проєкт вже використовує Jest, більшість тестових файлів можна переключити на bun test без змін. API-поверхня майже ідентична. Головна різниця — швидкість: тести, що займали 30 секунд з Jest, завершаться приблизно за 1-2 секунди з Bun.
Bun надає офіційні Docker-образи, які менші та запускаються швидше за аналоги Node.js.
Створіть продакшен Dockerfile
FROM oven/bun:1.3 AS base
WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile --production
COPY src ./src
EXPOSE 3000
CMD ["bun", "run", "src/server.ts"]Зберіть образ та запустіть контейнер
docker build -t my-bun-server .
docker run -p 3000:3000 my-bun-serverThe container starts in under a second. Bun's cold start advantage (8-15ms vs 40-120ms for Node.js) is especially valuable in container orchestration environments where frequent restarts and scaling events are normal.
Ці бенчмарки походять від кількох незалежних джерел, що тестували Fastify на Bun проти Fastify на Node.js на ідентичному обладнанні та навантаженнях.
Розрив у продуктивності між Bun та Node.js найбільш виражений у сирій HTTP-пропускній здатності та холодних запусках. Коли в картину входять накладні витрати фреймворку (middleware Fastify, JSON-серіалізація, валідація), розрив звужується до 40-70%. У реальних API, де домінують запити до бази даних та мережевий I/O, рантайм становить менше 10% загального часу запиту. Найбільші практичні переваги — у швидкості запуску, часу CI/CD пайплайну та конкурентності WebSocket. [1][2][3]
95,200 vs 55,800
Bun забезпечує ~70% більшу пропускну здатність Fastify порівняно з Node.js на ідентичному обладнанні. [3]
156ms vs 245ms
Bun запускається ~36% швидше, зменшуючи витрати на serverless-функції безпосередньо. [2]
1.2M vs 680K
Bun обробляє на 76% більше конкурентних WebSocket-з'єднань на тому ж обладнанні. [1]
380MB vs 512MB
Контейнери Bun використовують ~25% менше пам'яті, дозволяючи більше подів на кластер. [1]
2s vs 30s
Менеджер пакетів Bun встановлює залежності на 10-15x швидше за npm. [1]
1.2s vs 24s
Тест-раннер Bun ~20x швидший за Jest із сумісним API. [1]
Коли цифри мають найбільше значення
Перевага в продуктивності Bun найбільша для serverless-функцій (холодний старт), CI/CD пайплайнів (швидкість встановлення + тестування) та застосунків з інтенсивним використанням WebSocket. Для стандартних REST API, де база даних є вузьким місцем, різниця менша, але все ще значуща — особливо в масштабі.
Це проблеми, з якими команди реально стикаються при розгортанні Bun у продакшені.
Припущення 100% сумісності з npm. Приблизно 2% пакетів — переважно нативні C++ додатки, скомпільовані через node-gyp — можуть не працювати. Типові проблемні пакети включають bcrypt (використовуйте bcryptjs), певні реалізації canvas та node-sass (використовуйте sass). Завжди виконуйте bun install && bun test перед комітом. [1][2]
Ігнорування відмінностей збирача сміття Bun. Bun використовує збирач сміття JSC, який менш перевірений для процесів, що працюють безперервно 72+ годин, порівняно з V8. Для довготривалих сервісів, моніторте поведінку пам'яті протягом 24-48 годин після міграції. [2]
Забування аудитувати нативні залежності перед Docker-збірками. Пакет, що встановлюється нормально з bun install на macOS, може не спрацювати під час Docker-збірок на Linux, якщо містить платформо-специфічні нативні бінарні файли. Тестуйте повний пайплайн збірки на ранньому етапі. [1]
Очікування, що весь middleware Express працюватиме без змін. Більшість middleware Express працює з Fastify (через адаптер @fastify/express), але деякі пакети покладаються на специфічні для Express мутації об'єктів request/response. Тестуйте кожен middleware окремо. [4]
Безпечний шлях міграції
Почніть з використання Bun як менеджера пакетів та тест-раннера, зберігаючи Node.js як рантайм. Це дасть вам 80-90% переваг у швидкості з нульовим ризиком для продакшену. Переключайте рантайм на Bun лише після того, як повний набір тестів пройде і ви перевірите поведінку пам'яті в staging.
Обидва рантайми готові до продакшену в 2026 році. Вибір залежить від ваших конкретних обмежень.
Оберіть Bun для нових проєктів
Ви контролюєте дерево залежностей. Ви хочете нативний TypeScript, швидший CI/CD, нижчі витрати на serverless або максимальну HTTP-пропускну здатність. Сумісність відмінна для стандартних веб-фреймворків (Fastify, Hono, Express) та ORM (Prisma, Drizzle, TypeORM).
Залиште Node.js для існуючих проєктів
Ваш застосунок має сотні залежностей, нативні C++ додатки або роки продакшен-загартування. Переваги в продуктивності рідко виправдовують вартість міграції, коли рантайм не є вузьким місцем — запити до бази даних та мережевий I/O зазвичай домінують.
Використовуйте гібридний підхід
Bun для інструментів (управління пакетами, тестування) + Node.js для продакшен-рантайму. Це прагматичний enterprise-патерн: на 80-90% швидший CI/CD з нульовим ризиком міграції. Кілька компаній з Fortune 500 прийняли саме цей патерн у 2026 році.
Короткі відповіді на поширені питання про запуск Fastify на Bun.
Чи працює Fastify на Bun без змін?
Чи потрібен мені tsconfig.json з Bun?
Не для базового виконання. Bun запускає файли .ts нативно. Вам потрібен tsconfig.json лише якщо ви хочете сувору перевірку типів в IDE або якщо інші інструменти (ESLint, автозаповнення IDE) на нього посилаються. Bun ігнорує tsconfig.json під час виконання. [1]
Чи можу я використовувати Prisma з Bun?
Як щодо гарячого перезавантаження в розробці?
Bun надає bun --hot, який зберігає стан застосунку між перезавантаженнями — швидше за прапорець --watch Node.js, що перезапускає весь процес. Для Fastify це означає, що ваш сервер перезапускається за мілісекунди замість секунд. [1]
Чи безпечний Bun для продакшену в 2026?
Як Bun порівнюється з Deno?
Bun швидший за Deno у більшості бенчмарків. Deno має сильнішу модель безпеки (вбудовані дозволи), але повільніше впровадження. Для випадку використання цього посібника (сервер Fastify), Bun має кращу сумісність фреймворків та швидший тест-раннер. [2]
Джерела, що підтверджують твердження про функції рантайму Bun, бенчмарки продуктивності, сумісність Fastify та стан екосистеми.
• 1. Bun — Офіційна документація (рантайм, менеджер пакетів, тест-раннер, bun:sqlite)
• 2. Tech Insider — Bun vs Node.js: 3x Faster, But Is It Ready? [2026]
• 3. fishuke/nest-bun — NestJS Express vs Bun бенчмарки (GitHub)
• 4. Fastify — Офіційна документація (Getting Started, Server, Validation)
• 5. Strapi — Bun vs Node.js 2025: Performance, Speed & Developer Guide
• 6. daily.dev — Bun vs Node.js vs Deno: JavaScript Runtimes Compared in 2026
Якщо ви оцінюєте Bun для вашого бекенд-стеку, PAS7 Studio може допомогти вам оцінити сумісність, побудувати шлях міграції та запустити продакшен-готовий сервер Bun + Fastify з валідацією, інтеграцією бази даних, автентифікацією та автоматизацією розгортання.
Ми маємо досвід з Bun, Fastify, NestJS, PostgreSQL, Docker та повним бекенд-стеком. Незалежно від того, чи ви починаєте з нуля чи мігруєте з Node.js, ми допоможемо уникнути поширених помилок та отримати переваги продуктивності без сюрпризів.
Bun.js сервер із Fastify: від нуля до продакшену
Пов'язані статті
AI SEO / GEO у 2026: ваші наступні клієнти — не люди, а агенти
Пошук зміщується від кліків до відповідей. Боти та AI-агенти сканують, цитують, рекомендують і дедалі частіше купують. Дізнайтесь, що таке AI SEO / GEO, чому класичного SEO вже недостатньо, і як PAS7 Studio допомагає брендам перемагати у «агентному» вебі.
Найпотужніший чіп від Apple? M5 Pro і M5 Max б'ють рекорди
Аналітичний розбір Apple M5 Pro і M5 Max станом на березень 2026 року. Пояснюємо, чому ці чіпи можна вважати найпотужнішими професійними ноутбучними SoC від Apple, як вони виглядають на тлі M4 Pro, M4 Max, M1 Pro, M1 Max і що показують у порівнянні з актуальними Intel та AMD.
Artemis II і код, який веде до Місяця
У цьому блозі розбираємо місію NASA Artemis II, яка стартувала 1 квітня 2026 року, і пояснюємо, що вона насправді говорить про сучасну інженерію: бортове ПЗ, резервні контури, симуляції, телеметрію, людський контроль і дуже обережну роль ШІ в космічній сфері.
Автоматичне тегування та пошук збережених посилань
Інтеграція з GDrive/S3/Notion для автоматичного тегування та швидкого пошуку через пошукові API
Професійна розробка для вашого бізнесу
Створюємо сучасні веб-рішення та боти для бізнесу. Дізнайтеся, як ми можемо допомогти вам досягти цілей.