Bun est le runtime JavaScript qui a bouleversé l’écosystème serveur depuis 2023. Trois ans plus tard, en 2026, c’est devenu une option crédible — voire préférable — pour tout nouveau projet backend Node.js. Plus rapide, plus léger, avec une API plus moderne et un toolchain unifié (runtime + bundler + test runner + package manager), Bun arrive en version 1.x stable adoptée en production par Cloudflare, Discord, Vercel pour certains pipelines, et de nombreuses startups. Pour les développeurs et PME en Afrique de l’Ouest, Bun apporte un avantage concret : moins de RAM consommée, démarrages plus rapides, et donc des VPS moins chers pour le même niveau de service. Voici le guide complet pour utiliser Bun en production en 2026.

Ce pilier couvre tout : pourquoi choisir Bun, comment l’installer, comment construire une API, comment l’utiliser avec PostgreSQL, comment le déployer, comment le superviser et comment l’adapter au contexte ouest-africain. Les satellites détaillent les sujets pointus : Bun + Hono pour les API REST, Bun + Drizzle ORM avec PostgreSQL, déploiement avec systemd ou PM2, et benchmarks réels Bun vs Node.js.

Pourquoi Bun en 2026 ?

Bun, créé par Jarred Sumner et porté par la société Oven, est un runtime JavaScript écrit en Zig (un langage moderne similaire à Rust en termes de performance) qui utilise le moteur JavaScriptCore d’Apple plutôt que V8 utilisé par Node.js et Deno. Cette différence fondamentale lui donne plusieurs avantages mesurables :

Démarrage 4 à 8 fois plus rapide que Node.js sur les scripts simples — important pour les serverless, les CLI, et les conteneurs qui démarrent souvent.
HTTP server natif environ 2 à 3 fois plus rapide que Node.js pour les requêtes simples, grâce à une implémentation directe en Zig (pas de wrapper JavaScript autour de libuv).
Empreinte mémoire 30 à 50 % plus faible que Node.js sur des charges identiques, ce qui change tout sur un VPS de 2-4 Go RAM.
Toolchain unifié : bun remplace node, bun install remplace npm install (et est 10 à 30x plus rapide), bun test remplace Jest/Vitest, bun build remplace esbuild ou webpack pour les builds. Plus de jongle entre plusieurs outils.
Support TypeScript natif sans configuration : bun run app.ts fonctionne directement.
Compatibilité Node.js très avancée : la grande majorité des packages npm fonctionnent sans modification. Compatible avec les API node:fs, node:http, node:crypto, etc.
Bun.serve() : un serveur HTTP natif extrêmement performant qui supporte WebSockets, HTTP/2 et HTTPS.

Comparativement, Deno (créé par Ryan Dahl, le créateur original de Node.js) reste excellent mais moins rapide en bench, et Node.js reste le plus mature et le plus large en compatibilité. En 2026, Bun est le choix recommandé pour tout nouveau projet où la performance et l’empreinte mémoire comptent (api.startup, microservices, edge functions, scripts CLI).

Prérequis

Linux (Ubuntu 22.04+, Debian 12+) ou macOS pour le développement
Connaissance basique de TypeScript ou JavaScript moderne (ES2022+)
Pour la production : un VPS Linux avec au moins 1 Go RAM (Bun consomme peu)
Niveau attendu : intermédiaire — vous avez déjà fait du Node.js
Temps : 1 heure pour démarrer un projet, 2 heures pour comprendre les spécificités, 4 heures pour mettre en prod

Étape 1 — Installer Bun

Sur Linux et macOS :

curl -fsSL https://bun.sh/install | bash

# Recharger le shell ou ajouter à .bashrc
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"

# Vérifier
bun --version
# Devrait afficher 1.x.x

Sur Windows, utilisez WSL2 ou bun.exe (en preview en 2026 mais utilisable). Pour les VPS de production, je recommande d’installer Bun globalement comme binaire unique dans /usr/local/bin/bun pour qu’il soit accessible à tous les utilisateurs.

Étape 2 — Créer un projet Bun

mkdir mon-api && cd mon-api
bun init

# Génère :
# - package.json
# - tsconfig.json (TypeScript par défaut)
# - index.ts (point d'entrée)
# - .gitignore

# Lancer
bun run index.ts

Le package.json généré utilise bun comme runtime par défaut. Bun peut aussi exécuter du code Node.js classique sans changement, mais vous gagnez à utiliser les API natives Bun (Bun.serve, Bun.file, Bun.password) qui sont plus performantes.

Étape 3 — Premier serveur HTTP avec Bun.serve()

L’API native Bun.serve est le moyen le plus performant de servir du HTTP avec Bun :

// index.ts
const server = Bun.serve({
  port: 3000,
  hostname: "0.0.0.0",

  async fetch(req) {
    const url = new URL(req.url);

    if (url.pathname === "/") {
      return new Response("Hello from Bun!");
    }

    if (url.pathname === "/api/health") {
      return Response.json({ status: "ok", time: Date.now() });
    }

    if (url.pathname === "/api/echo" && req.method === "POST") {
      const body = await req.json();
      return Response.json({ received: body });
    }

    return new Response("Not Found", { status: 404 });
  },
});

console.log(`Listening on http://localhost:${server.port}`);

Lancez avec bun run index.ts. Le serveur démarre en quelques millisecondes et tient facilement plusieurs milliers de requêtes par seconde sur un VPS modeste.

Étape 4 — Utiliser un framework

Pour les API plus complexes (routing avancé, middlewares, validation), un framework apporte de la structure. Les choix recommandés pour Bun en 2026 :

Hono — léger, rapide, type-safe, fonctionne sur Bun, Node.js, Deno, Cloudflare Workers. C’est le choix par défaut. Voir notre tutoriel Bun + Hono.
Elysia — un framework TypeScript-first conçu pour Bun, avec validation de schéma intégrée et type-safety end-to-end via Eden treaty.
Express — fonctionne mais perd l’avantage performance de Bun. Utile uniquement pour migrer une app Node.js existante.

Étape 5 — Base de données et ORM

Bun dispose d’un client SQLite intégré (bun:sqlite) extrêmement rapide, parfait pour les petites apps ou les caches locaux. Pour PostgreSQL en production, utilisez :

postgres.js — client Postgres léger et performant, fonctionne nativement avec Bun
Drizzle ORM — ORM TypeScript-first, type-safe, sans génération de code, excellent avec Bun. Voir notre tutoriel Bun + Drizzle.
Prisma — fonctionne avec Bun depuis 2024, mais l’overhead du runtime engine peut réduire l’avantage perf de Bun

Étape 6 — Tests avec bun test

bun test est un test runner intégré, compatible avec la syntaxe Jest, sans configuration. Exemple :

// math.test.ts
import { describe, it, expect } from "bun:test";

function add(a: number, b: number) {
  return a + b;
}

describe("add()", () => {
  it("adds two positive numbers", () => {
    expect(add(2, 3)).toBe(5);
  });

  it("handles negative", () => {
    expect(add(-1, 1)).toBe(0);
  });
});

Lancez avec bun test. Le runner est environ 10x plus rapide que Jest sur un projet typique grâce à l’absence de transpilation à chaque run.

Étape 7 — Build pour la production

Bun peut bundler votre application en un seul fichier exécutable :

# Bundler en un seul fichier JS
bun build ./index.ts --outfile=./dist/server.js --target=bun

# Ou compiler en binaire standalone (incluant le runtime Bun)
bun build ./index.ts --compile --outfile=./dist/server

L’option --compile produit un binaire de quelques dizaines de Mo qui inclut le runtime — vous pouvez le déployer sans installer Bun sur le serveur cible. Pratique pour des conteneurs Docker minimalistes.

Étape 8 — Déployer en production

Pour déployer une application Bun, plusieurs options selon votre contexte :

Coolify avec Nixpacks : Coolify détecte Bun automatiquement si bun.lockb ou bun.lock est présent dans le repo. Déploiement en un clic depuis Git.
systemd sur un VPS Linux nu : créer un service systemd qui lance bun run start. Voir notre guide systemd / PM2.
Docker : utiliser l’image officielle oven/bun ou compiler en binaire avec bun build --compile et l’inclure dans une image Alpine minimale.
PM2 : compatible avec Bun via pm2 start --interpreter bun ./index.ts. Utile si votre infrastructure utilise déjà PM2.

Performance et benchmarks

Sur un VPS Hetzner CX22 (4 Go RAM, 2 vCPU, environ 4 € par mois), une API Bun + Hono + Drizzle + PostgreSQL avec 100 endpoints peut tenir 15 000 à 25 000 requêtes par seconde sur des routes simples (sans calcul lourd côté DB). Le même setup sous Node.js + Express + Prisma tient autour de 5 000 à 10 000 RPS. Bun consomme typiquement 80-120 Mo RAM en idle, contre 150-200 Mo pour Node.js.

Notre comparatif benchmarks Bun vs Node.js 2026 détaille les chiffres avec méthodologie reproductible.

Adaptation Afrique de l’Ouest

Pour les développeurs et PME au Sénégal, Côte d’Ivoire, Mali, Burkina Faso : Bun apporte un avantage économique direct. Avec un VPS Hetzner CX22 à 4 € par mois, vous pouvez héberger 5 à 10 microservices Bun moyens, là où Node.js demanderait un VPS double pour les mêmes performances. Sur un an, l’économie est de 50 à 100 € par projet.

L’autre avantage est le démarrage rapide : si vous utilisez Coolify pour déployer plusieurs apps qui démarrent à la demande (workers, batch jobs, scripts cron), Bun démarre en 50 ms contre 500-800 ms pour Node.js. Ça réduit considérablement la latence perçue par l’utilisateur final lors du premier appel « froid ».

Erreurs fréquentes

Erreur	Cause	Solution
Package npm ne fonctionne pas	Dépend d’API Node spécifiques non implémentées	Vérifier compat sur bun.sh/docs/ecosystem, signaler issue
bun.lockb conflit Git	Fichier binaire	Utiliser bun.lock (text) en 2026 — option dans bunfig.toml
Bun.serve crash silencieux	Erreur dans handler async non catchée	Toujours envelopper dans try/catch et logger
Memory leak avec WebSocket	Pas de cleanup sur disconnect	Utiliser server.publish() proprement, fermer les listeners
Module ESM/CJS mixed	Package legacy CJS	type:module dans package.json + import explicite
Tests qui passent en local mais pas en CI	Différence de version Bun	Pinner la version dans CI : bun –version dans bunfig.toml

Pour aller plus loin

Bun + Hono : construire une API REST type-safe
Bun + Drizzle ORM avec PostgreSQL
Déployer Bun en production : systemd ou PM2
Bun vs Node.js : benchmarks réels 2026
Documentation officielle : bun.sh/docs
Hono framework : hono.dev
Drizzle ORM : orm.drizzle.team

FAQ

Bun est-il prêt pour la production en 2026 ?

Oui, Bun 1.x est stable depuis 2023 et utilisé en production par Cloudflare, Discord, et de nombreuses startups. La compatibilité avec l’écosystème npm dépasse les 95 % des packages courants. Pour un nouveau projet en 2026, Bun est un choix solide.

Faut-il migrer un projet Node.js existant ?

Pas forcément. Si votre projet Node.js fonctionne bien et n’a pas de problème de performance ou de coût, la migration n’est pas urgente. Pour de nouveaux services ou microservices ajoutés au projet, démarrer en Bun est rentable. Pour migrer un projet existant, comptez 1 à 5 jours selon la complexité.

Bun fonctionne-t-il avec TypeScript ?

Oui, nativement, sans configuration. bun run app.ts exécute du TypeScript directement. Bun fait du transpiling à la volée, équivalent à ts-node mais beaucoup plus rapide. Pour les types stricts en production, gardez tsc --noEmit en CI pour vérifier les types.

Quelle différence avec Deno ?

Deno (de Ryan Dahl, créateur de Node.js) mise sur la sécurité par défaut (permissions explicites) et un toolchain unifié. Bun mise sur la performance brute et la compatibilité Node.js. Bun est plus rapide en bench, Deno est plus sûr par design. Les deux sont excellents.

Bun en production 2026 : guide complet (runtime JavaScript moderne)