Come configurare un server Bun.js con Fastify: da zero a produzione
Una guida pratica per creare un server Bun.js pronto per la produzione con Fastify. Installa Bun, crea un server HTTP, aggiungi route TypeScript, gestisci la validazione, connetti un database e effettua il deploy — con benchmark che mostrano le differenze di prestazioni tra Bun + Fastify e Node.js + Fastify.
Guida alla Configurazione del Server Bun 2026
Una guida in due parti per costruire server pronti per la produzione con Bun. La Parte 1 copre le basi del runtime Bun e la configurazione di Fastify. La Parte 2 copre NestJS su Bun e l'ottimizzazione delle prestazioni.
Tutti gli articoli di questa guida
01
Server Bun.js con Fastify: da zero a produzione
Installa Bun, crea un server HTTP, aggiungi route TypeScript con Fastify, gestisci la validazione, connetti un database ed effettua il deploy con Docker.
02
NestJS su Bun.js: configurazione e ottimizzazione delle prestazioni
Esegui NestJS su Bun, configura SWC, abilita il lazy loading dei moduli, passa all'adattatore Fastify e applica le ottimizzazioni delle prestazioni.
In breve
Questa è una guida pratica, da zero a un server funzionante. Non è richiesta esperienza pregressa con Bun.
Bun.serve() (nativo) e fastify.listen() (framework)bun:sqlite)Se hai costruito server con Node.js, la maggior parte delle tue conoscenze si trasferisce direttamente. Le differenze più importanti riguardano l'architettura del motore, il tooling integrato e la gestione di 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) |
Conclusione
Per nuovi progetti server, Bun offre un runtime più veloce, una toolchain più semplice e TypeScript nativo. Il restante 2% di incompatibilità npm è concentrato in addon nativi C++ come bcrypt o node-sass — la maggior parte dei framework web e degli ORM funzionano senza modifiche.
Bun si installa come singolo binario. Non servono Node.js, npm o strumenti di build separati.
Installazione tramite curl
curl -fsSL https://bun.sh/install | bashQuesto scarica il binario di Bun, lo aggiunge al tuo PATH e verifica l'installazione. Dopo l'installazione, esegui bun --version per confermare.
Installazione tramite PowerShell
powershell -c "irm bun.sh/install.ps1|iex"Il supporto per Windows ha raggiunto lo stato stabile con Bun 1.3. Tutte le funzionalità principali — runtime, gestore di pacchetti, test runner e bundler — funzionano su Windows. [1]
Confermare l'installazione
bun --versionDovresti vedere 1.3.x o successivo. Bun è pronto. Non è necessaria un'installazione separata di Node.js per i progetti Bun, sebbene avere Node.js installato insieme a Bun sia comune e funzioni senza conflitti.
Crea la directory del progetto, installa Fastify e scrivi il primo file server — tutto in TypeScript, senza alcun passaggio di build.
Crea il progetto e installa le dipendenze
mkdir my-bun-server && cd my-bun-server
bun init
bun add fastifybun init crea un package.json minimale con "type": "module" impostato. bun add fastify installa Fastify da npm — il gestore di pacchetti di Bun scarica e risolve le dipendenze 10-30 volte più velocemente di npm. [1]
Crea il punto di ingresso del server
// 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();Questo è codice Fastify standard. L'unica differenza rispetto a Node.js: lo esegui con bun invece di node, e l'estensione .ts funziona direttamente.
Avvia il server
bun run server.tsQuesto è tutto. Niente tsc, niente ts-node, niente nodemon, nessun passaggio di build. Bun legge il file TypeScript, rimuove i tipi al momento del parsing e lo esegue. Per lo sviluppo con hot reload, usa bun --hot server.ts — Bun preserva lo stato dell'applicazione tra i ricarichi, il che è più veloce del flag --watch di Node.js che riavvia l'intero processo. [1]
Cosa è appena successo
Hai creato un server Fastify funzionante in TypeScript con due comandi (bun init e bun add fastify) e un file (server.ts). Nessun file di configurazione, nessuno strumento di build, nessun passaggio di transpilazione. Questa è la differenza fondamentale nell'esperienza di sviluppo tra Bun e Node.js.
Bun offre due modi per creare server HTTP: l'API nativa Bun.serve() e framework di terze parti come Fastify. Entrambi girano sul runtime di Bun, ma rispondono a esigenze diverse.
Bun.serve() è il server HTTP integrato di Bun. È l'opzione più veloce — i benchmark mostrano circa 180.000 richieste/sec per risposte in testo piano rispetto alle 65.000 richieste/sec di Node.js. È ideale per API semplici, microservizi ed endpoint critici per le prestazioni dove si desidera un overhead minimo. [1][3]
Fastify aggiunge uno strato strutturato sopra: validazione JSON Schema, ottimizzazione della serializzazione, architettura a plugin, hook e decorator. Eseguire Fastify su Bun ti offre circa 95.200 req/s rispetto a circa 55.800 req/s su Node.js — circa il 70% di throughput in più. Perdi un po' di velocità pura rispetto a Bun.serve(), ma guadagni un framework di livello produttivo con validazione, gestione degli errori ed estensibilità. [3]
Per la maggior parte delle applicazioni reali, Fastify su Bun è la scelta pragmatica. L'overhead del framework è una frazione del tempo totale della richiesta quando aggiungi query al database, autenticazione e logica di business. La sola validazione dello schema — che Fastify gestisce a livello framework con un incremento di velocità di serializzazione di 2-3x — spesso giustifica la scelta. [4][5]
Usa Bun.serve() quando
Hai bisogno della massima velocità grezza per endpoint semplici. Stai costruendo un proxy leggero, un servizio di health check, un ricevitore di webhook o un microservizio interno. Vuoi il cold start più piccolo possibile per deploy serverless. Sei a tuo agio nella gestione manuale di routing, validazione e gestione degli errori.
Usa Fastify su Bun quando
Hai bisogno di validazione e serializzazione JSON Schema. Vuoi un ecosistema di plugin (CORS, auth, Swagger, rate limiting). Stai costruendo un'API REST o GraphQL con route multiple. Vuoi una gestione strutturata degli errori e hook del ciclo di vita della richiesta. Hai bisogno di strumenti di sviluppo di livello produttivo.
Evita Bun.serve() quando
La tua API ha requisiti di validazione complessi. Hai bisogno di generazione di documentazione OpenAPI/Swagger. Dipendi da plugin specifici del framework. Il tuo team si aspetta pattern Express/Fastify per la mantenibilità.
Bun.serve() offre il throughput grezzo più alto, ma Fastify su Bun fornisce un buon equilibrio tra funzionalità del framework e prestazioni. Il divario reale tra Fastify su Bun e Fastify su Node.js è di circa il 70%.
Screenshot della sezione bun-serve-vs-fastifyIl punto di forza di Fastify è la validazione strutturata delle richieste tramite JSON Schema. Ecco come costruire route validate su Bun.
Crea un modulo di route validate
// 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" };
});
};Registra le route nel file server principale
// 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();Esegui con bun run server.ts. I body di richiesta non validi ora restituiscono automaticamente errori 400 strutturati.
Punto chiave
La validazione tramite schema di Fastify funziona in modo identico su Bun e Node.js. L'unica differenza è che il gestore validato viene eseguito più velocemente sul runtime di Bun. Se le tue route Fastify esistenti utilizzano JSON Schema, funzioneranno su Bun senza modifiche.
Bun supporta due percorsi per i database: il modulo integrato bun:sqlite per archiviazione locale leggera, e i driver di database npm standard per PostgreSQL, MySQL, MongoDB e altri database. Per PostgreSQL, il driver pg funziona su Bun senza modifiche. [1]
Per un layer ORM, Prisma, Drizzle ORM e TypeORM funzionano tutti su Bun. Prisma in particolare è ben collaudato — il team Prisma ha confermato la compatibilità con Bun e molti deploy di produzione utilizzano Prisma + Bun + PostgreSQL. [1][2]
Il modulo SQLite integrato di Bun (bun:sqlite) è utile per prototipazione, caching e deploy a singola istanza dove un database esterno è eccessivo. Per le API di produzione, PostgreSQL tramite pg o un ORM come Prisma è la scelta standard.
Consiglio pratico
Usa bun:sqlite per prototipazione e caching a singola istanza. Usa PostgreSQL + Prisma o Drizzle per le API di produzione. Entrambi funzionano su Bun senza modifiche alla configurazione oltre alla stringa di connessione al database.
Il test runner integrato di Bun utilizza API compatibili con Jest. La maggior parte dei file di test esistenti funziona senza modifiche.
Scrivere un test per le route
Crea un file di test utilizzando il test runner integrato di Bun. Importa describe, it ed expect da bun:test. L'API è compatibile con Jest, quindi i test NestJS/Fastify esistenti migrano con modifiche minime. Usa app.inject() per testare le route senza avviare un server HTTP reale. Esegui tutti i test con bun test, che scopre automaticamente i file corrispondenti a *.test.ts e *.spec.ts. Una suite di 500 test si completa in circa 1,2 secondi rispetto ai 24 secondi di Jest. [1]
Nota sulla migrazione
Se il tuo progetto utilizza già Jest, la maggior parte dei file di test può passare a bun test senza modifiche. La superficie API è quasi identica. La differenza principale è la velocità: i test che richiedevano 30 secondi con Jest si completano in circa 1-2 secondi con Bun.
Bun fornisce immagini Docker ufficiali più piccole e con avvio più rapido rispetto alle equivalenti Node.js.
Crea un Dockerfile di produzione
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"]Crea l'immagine e avvia il container
docker build -t my-bun-server .
docker run -p 3000:3000 my-bun-serverIl container si avvia in meno di un secondo. Il vantaggio del cold start di Bun (8-15ms contro 40-120ms per Node.js) è particolarmente prezioso negli ambienti di orchestrazione dei container dove riavvii frequenti ed eventi di scaling sono normali.
Questi benchmark provengono da molteplici fonti indipendenti che hanno testato Fastify su Bun rispetto a Fastify su Node.js con hardware e carichi di lavoro identici.
Il divario prestazionale tra Bun e Node.js è più marcato nel throughput HTTP grezzo e nei cold start. Quando entra in gioco l'overhead del framework (middleware Fastify, serializzazione JSON, validazione), il divario si riduce al 40-70%. Nelle API reali dove le query al database e l'I/O di rete dominano, il runtime conta per meno del 10% del tempo totale della richiesta. I maggiori vantaggi pratici si hanno nella velocità di avvio, nei tempi della pipeline CI/CD e nella concorrenza WebSocket. [1][2][3]
95,200 vs 55,800
Bun offre circa il 70% di throughput Fastify in più rispetto a Node.js su hardware identico. [3]
156ms vs 245ms
Bun si avvia circa il 36% più velocemente, riducendo direttamente i costi delle funzioni serverless. [2]
1.2M vs 680K
Bun gestisce il 76% in più di connessioni WebSocket contemporanee sullo stesso hardware. [1]
380MB vs 512MB
I container Bun usano circa il 25% di memoria in meno, consentendo più pod per cluster. [1]
2s vs 30s
Il gestore di pacchetti di Bun installa le dipendenze 10-15 volte più velocemente di npm. [1]
1.2s vs 24s
Il test runner di Bun è circa 20 volte più veloce di Jest con API compatibile. [1]
Quando i numeri contano di più
Il vantaggio prestazionale di Bun è maggiore per le funzioni serverless (cold start), le pipeline CI/CD (velocità di installazione + test) e le applicazioni intensive di WebSocket. Per le API REST standard dove il database è il collo di bottiglia, la differenza è minore ma comunque significativa — specialmente su larga scala.
Questi sono i problemi che i team incontrano realmente quando effettuano il deploy di Bun in produzione.
Dare per scontata una compatibilità npm al 100%. Circa il 2% dei pacchetti — principalmente addon nativi C++ compilati con node-gyp — potrebbe non funzionare. I pacchetti problematici comuni includono bcrypt (usare bcryptjs), alcune implementazioni di canvas e node-sass (usare sass). Esegui sempre bun install && bun test prima di fare commit. [1][2]
Ignorare le differenze del garbage collector di Bun. Bun utilizza il garbage collector di JSC, che è meno collaudato per processi in esecuzione continua per 72+ ore rispetto a quello di V8. Per i servizi a lunga esecuzione, monitora il comportamento della memoria per 24-48 ore dopo la migrazione. [2]
Dimenticarsi di auditare le dipendenze native prima dei build Docker. Un pacchetto che si installa correttamente con bun install su macOS potrebbe fallire durante i build Docker su Linux se include binari nativi specifici della piattaforma. Testa la pipeline di build completa il prima possibile. [1]
Usare le import con protocollo node: senza verifica. Bun supporta la maggior parte delle import dei moduli integrati node:, ma esistono casi limite in node:diagnostics_channel, node:vm e alcune API inspector. Se il tuo codice utilizza interni profondi di Node.js, testa ogni import esplicitamente. [1][2]
Aspettarsi che tutto il middleware Express funzioni senza modifiche. La maggior parte del middleware Express funziona con Fastify (tramite l'adattatore @fastify/express), ma alcuni pacchetti si basano su mutazioni specifiche degli oggetti request/response di Express. Testa ogni middleware individualmente. [4]
Il percorso di migrazione sicuro
Inizia utilizzando Bun come gestore di pacchetti e test runner mantenendo Node.js come runtime. Questo ti offre l'80-90% del beneficio di velocità con zero rischio di produzione. Passa al runtime Bun solo dopo che l'intera suite di test è superata e hai validato il comportamento della memoria in staging.
Entrambi i runtime sono pronti per la produzione nel 2026. La scelta dipende dalle tue specifiche esigenze.
Scegli Bun per nuovi progetti
Controlli l'albero delle dipendenze. Vuoi TypeScript nativo, CI/CD più rapida, costi serverless inferiori o il throughput HTTP massimo. La compatibilità è eccellente per i framework web standard (Fastify, Hono, Express) e gli ORM (Prisma, Drizzle, TypeORM).
Mantieni Node.js per progetti esistenti
La tua applicazione ha centinaia di dipendenze, addon nativi C++ o anni di hardening in produzione. I guadagni prestazionali raramente giustificano il costo della migrazione quando il runtime non è il collo di bottiglia — le query al database e l'I/O di rete sono solitamente i fattori dominanti.
Usa l'approccio ibrido
Bun per il tooling (gestione pacchetti, testing) + Node.js come runtime di produzione. Questo è il pattern enterprise pragmatico: CI/CD 80-90% più veloce con zero rischio di migrazione. Diverse aziende Fortune 500 hanno adottato questo esatto pattern nel 2026.
Risposte brevi alle domande più comuni sull'esecuzione di Fastify su Bun.
Fastify funziona su Bun senza modifiche?
Mi serve ancora tsconfig.json con Bun?
Non per l'esecuzione di base. Bun esegue i file .ts nativamente. Hai bisogno di tsconfig.json solo se vuoi il type checking rigoroso nel tuo IDE o se altri strumenti (ESLint, autocompletamento dell'IDE) vi fanno riferimento. Bun ignora tsconfig.json a runtime. [1]
Posso usare Prisma con Bun?
E per l'hot reload in sviluppo?
Bun fornisce bun --hot che preserva lo stato dell'applicazione tra i ricarichi — più veloce del flag --watch di Node.js che riavvia l'intero processo. Per Fastify, questo significa che il tuo server si riavvia in millisecondi invece che in secondi. [1]
Bun è sicuro per la produzione nel 2026?
Come si confronta Bun con Deno?
Bun è più veloce di Deno nella maggior parte dei benchmark. Deno ha un modello di sicurezza più forte (permessi integrati) ma un'adozione più lenta. Per il caso d'uso di questa guida (server Fastify), Bun ha una migliore compatibilità dei framework e un test runner più veloce. [2]
Fonti a supporto delle affermazioni sulle funzionalità del runtime Bun, i benchmark prestazionali, la compatibilità Fastify e lo stato dell'ecosistema.
• 1. Bun — Documentazione ufficiale (runtime, gestore di pacchetti, test runner, bun:sqlite)
• 2. Tech Insider — Bun vs Node.js: 3x Più Veloce, Ma È Pronto? [2026]
• 3. fishuke/nest-bun — Benchmark NestJS Express vs Bun (GitHub)
• 4. Fastify — Documentazione ufficiale (Guida introduttiva, Server, Validazione)
• 5. Strapi — Bun vs Node.js 2025: Prestazioni, Velocità e Guida per Sviluppatori
• 6. daily.dev — Bun vs Node.js vs Deno: Confronto tra Runtime JavaScript nel 2026
Se stai valutando Bun per il tuo stack backend, PAS7 Studio può aiutarti a valutare la compatibilità, costruire il percorso di migrazione e distribuire un server Bun + Fastify pronto per la produzione con validazione, integrazione del database, autenticazione e automazione del deploy.
Abbiamo esperienza con Bun, Fastify, NestJS, PostgreSQL, Docker e l'intero stack backend. Che tu stia partendo da zero o migrando da Node.js, possiamo aiutarti a evitare le trappole comuni e ottenere i benefici prestazionali senza sorprese.
Server Bun.js con Fastify: da zero a produzione
Articoli correlati
AI SEO / GEO nel 2026: i tuoi prossimi clienti non sono umani — sono agenti
La ricerca sta passando dai click alle risposte. Bot e agenti AI scansionano, citano, raccomandano e sempre più spesso acquistano. Scopri cosa significa AI SEO / GEO, perché la SEO classica non basta più e come PAS7 Studio aiuta i brand a vincere visibilità nel web “agentico”.
Il chip Apple più potente? M5 Pro e M5 Max battono i record
Analisi di Apple M5 Pro e M5 Max aggiornata a marzo 2026. Spieghiamo perché questi chip possono essere considerati i SoC professionali per notebook più potenti di Apple, come si posizionano contro M4 Pro, M4 Max, M1 Pro, M1 Max e cosa mostrano rispetto ai concorrenti Intel e AMD.
Tag automatici e ricerca per link salvati
Integra con GDrive/S3/Notion per tag automatici e ricerca veloce tramite API di ricerca
Sviluppo di bot e servizi di automazione
Sviluppo professionale di bot Telegram e automazione dei processi aziendali: chatbot, assistenti AI, integrazioni CRM, automazione dei flussi di lavoro.
Sviluppo professionale per la tua attività
Creiamo soluzioni web moderne e bot per le aziende. Scopri come possiamo aiutarti a raggiungere i tuoi obiettivi.