Vercel laisse enfin déployer Bun.serve tel quel dans ses Functions

Vercel ajoute une évolution très concrète pour les équipes qui testent Bun (runtime JavaScript et TypeScript alternatif à Node.js) côté backend léger : Bun.serve() est maintenant accepté comme entrée directe d’une Vercel Function. L’annonce est datée du 10 août 2026 et précise que cela couvre aussi les WebSockets (canal réseau persistant pour échanger des messages en temps réel), avec l’idée centrale suivante : le serveur Bun lancé en local peut être déployé “as-is” sur Vercel, sans être ré-encapsulé dans un framework. (vercel.com)

Ce qui change concrètement

Jusqu’ici, le point notable de l’annonce n’est pas une nouvelle API Bun, mais la compatibilité de la plateforme Vercel avec ce mode d’entrée. Pour l’activer, Vercel demande de définir "bunVersion": "1.x" dans vercel.json. Le point d’entrée attendu est un fichier server.ts à la racine du projet, dans lequel on crée un serveur Bun.serve() avec une table routes (mappage d’URL vers des handlers, c’est-à-dire des fonctions qui répondent aux requêtes). L’exemple publié par Vercel montre trois cas pris en charge : route statique, route dynamique avec paramètre, et route joker /*. (vercel.com)

{
  "bunVersion": "1.x"
}

WebSockets sans couche intermédiaire

L’autre changement utile concerne le temps réel. Vercel documente un schéma où l’on ajoute un bloc websocket au serveur, puis où fetch(request, server) appelle server.upgrade(request) pour transformer une requête HTTP en connexion WebSocket sur un chemin donné, par exemple /ws. L’exemple officiel garde le reste du serveur inchangé et montre un handler message qui renvoie le message reçu, autrement dit un serveur d’écho minimal. Pour un développeur habitué à Node.js, l’intérêt est clair : moins d’adaptation spécifique à la plateforme, donc moins de glue code (code de raccord) entre le serveur local et la version déployée. (vercel.com)

Bun.serve({
  routes: {
    "/health": Response.json({ status: "ok" }),
  },
  fetch(request, server) {
    const { pathname } = new URL(request.url);
    if (pathname === "/ws" && server.upgrade(request)) return;
    return new Response("Not found", { status: 404 });
  },
  websocket: {
    message(socket, message) {
      socket.send(message);
    },
  },
});

Ce que cela implique côté architecture

Vercel précise que les connexions WebSocket s’exécutent sur Fluid Compute (mode d’exécution maison de Vercel pour ses fonctions) avec une tarification à l’“Active CPU”, c’est-à-dire facturée sur le temps de traitement effectif des messages, pas sur le temps d’inactivité de la connexion. La plateforme indique aussi qu’une connexion reste attachée à une instance de fonction pendant toute sa durée de vie, et qu’une même instance peut gérer plusieurs connexions simultanées. En revanche, dès que votre logique doit diffuser ou synchroniser des messages entre plusieurs instances, Vercel recommande un stockage externe pour coordonner cet état partagé. Pour un système de chat, de présence ou d’événements temps réel, c’est le point d’attention principal : la connexion est locale à l’instance, l’état global ne l’est pas. (vercel.com)

Pourquoi ça mérite votre attention

Si vous êtes surtout côté Next.js / Node.js, cette annonce ne remplace pas votre pile du jour au lendemain. En revanche, elle rend Bun plus crédible sur un cas précis : déployer un petit serveur HTTP ou WebSocket sans framework serveur additionnel, avec un chemin plus direct entre développement local et production. Le gain n’est pas dans une promesse marketing floue, mais dans trois éléments factuels annoncés par Vercel : entrée Bun.serve() native, support WebSocket, déploiement du serveur tel quel. Pour les équipes qui expérimentent des backends périphériques — webhook, API légère, tunnel temps réel, endpoint de santé ou service de diffusion — c’est une simplification réelle du modèle de déploiement. (vercel.com)