Le 9 octobre 2026, Cloudflare a annoncé l'acquisition de Deno, le runtime JavaScript/TypeScript co-fondé par Ryan Dahl — l'auteur originel de Node.js — et par Bert Belder. L'ensemble de l'équipe Deno rejoint Cloudflare pour fusionner deux projets qui convergent depuis plusieurs années : le runtime Workers côté Cloudflare, et l'architecture celld développée par Deno cet été.
L'annonce change plusieurs réalités concrètes pour les équipes qui hébergent des fonctions sur Deno Deploy ou évaluent un runtime serverless JavaScript. Deno Deploy ferme sous six mois, les utilisateurs payants seront migrés vers Cloudflare Workers, et le runtime Deno open source passera en mode maintenance pendant un an avant la fin de son développement actif.
Cet article décortique les faits confirmés, la mécanique technique de la fusion celld/workerd, le calendrier de migration et les questions pratiques que les équipes techniques devraient poser maintenant.
L'acquisition : toute l'équipe Deno chez Cloudflare
Les faits annoncés le 9 octobre 2026
Cloudflare a confirmé l'accord le 9 octobre 2026 via un billet officiel. Les termes financiers n'ont pas été divulgués. Deno avait levé environ 26 millions de dollars, dont une série A menée par Sequoia. L'acquisition valorise donc un projet qui avait réussi à construire un runtime JavaScript natif TypeScript, un service d'hébergement edge (Deno Deploy) et, plus récemment, une implémentation Rust des Workers Cloudflare sous le nom celld.
Ryan Dahl, co-fondateur de Deno et créateur historique de Node.js, a commenté directement : « Nous rejoignons Cloudflare pour faire du modèle de programmation Workers une façon grand public de construire des serveurs. » Bert Belder, co-fondateur et architecte de celld, dirige avec Dahl les travaux d'intégration dans workerd, le runtime open source de Cloudflare.
Pourquoi Cloudflare avait-il besoin de Deno ?
Cloudflare Workers repose sur V8 Isolates pour exécuter des fonctions JavaScript à la périphérie du réseau. Le modèle est rapide et économique, mais son API de programmation — construite sur des standards W3C et des extensions propriétaires — restait difficile à adopter pour des équipes habituées à Node.js. Deno avait résolu une partie de ce problème en proposant un runtime qui suit les standards web tout en offrant TypeScript natif et une sécurité par défaut.
En août 2026, Deno avait publié celld : une réécriture en Rust du runtime Workers, conçue pour être embeddable, portable et plus performante que l'implémentation V8 Isolates existante. Cloudflare a vu dans cette brique l'opportunité de moderniser son moteur d'exécution tout en récupérant une équipe expérimentée dans la construction de runtimes JavaScript de bas niveau.
celld dans workerd : la vraie raison technique
Qu'est-ce que celld ?
celld est une implémentation Rust de l'API Cloudflare Workers, publiée par Deno en open source en août 2026. L'objectif initial était de permettre à des outils tiers de faire tourner localement des Workers sans dépendre des émulateurs existants, souvent incomplets. celld implémente fidèlement les APIs Workers — KV, R2, Queues, Durable Objects — avec une signature identique à ce que Cloudflare exécute en production.
La fusion avec workerd
workerd est le runtime open source que Cloudflare utilise en interne pour ses Workers. Il est aujourd'hui basé sur V8 et expose les APIs via un binding C++ vers JavaScript. L'intégration de celld dans workerd vise à remplacer progressivement cette couche par du Rust, ce qui améliore la portabilité (exécution hors Cloudflare), la reproductibilité locale et potentiellement les performances à froid.
Bert Belder et Ryan Dahl mèneront ce chantier directement chez Cloudflare. Le travail est public : workerd est sous licence Apache 2.0 sur GitHub, et les contributions de l'équipe Deno y seront visibles. Pour les développeurs qui utilisent l'architecture serverless dans leurs projets, cette convergence signifie un outillage local plus fidèle à la production et une meilleure portabilité cross-plateformes à terme.
Ce que ça change pour les développeurs Workers aujourd'hui
À court terme, rien ne change dans l'API Workers ni dans les comportements de production. La fusion celld/workerd est un chantier interne avec une visibilité externe via les commits open source. Les développeurs qui testent localement avec Miniflare pourront surveiller les mises à jour de workerd pour bénéficier d'une parité locale accrue. Nos projets sur mesure qui utilisent déjà Workers n'ont aucune action immédiate à prendre côté runtime.
Deno Deploy fermé sous 6 mois : ce qu'il faut planifier
Le calendrier de fermeture
Deno Deploy, le service d'hébergement géré de Deno, fermera dans les six mois suivant l'acquisition. La date exacte n'a pas été communiquée au moment de l'annonce, mais des communications directes seront envoyées aux utilisateurs payants. Ces derniers seront migrés vers Cloudflare Workers, qui propose un modèle équivalent : déploiement à la périphérie, persistance via KV et R2, domaines personnalisés.
Qui est concerné ?
Si vous avez des fonctions déployées sur Deno Deploy — qu'il s'agisse d'APIs légères, de webhooks, de proxies ou de SSR — vous devez initier votre migration vers Cloudflare Workers dans les prochaines semaines. Les principaux points de migration :
- API de fonctions : les handlers Deno Deploy suivent le standard
Request/ResponseWeb, identique à Workers. La logique métier migre généralement sans modification. - Variables d'environnement : Workers propose le même mécanisme via le dashboard ou Wrangler CLI.
- Domaines personnalisés : à reconfigurer dans Cloudflare DNS, ce qui est simplifié si votre domaine est déjà derrière Cloudflare.
- Stockage KV : Deno KV (basé sur FoundationDB) n'a pas d'équivalent direct dans Workers KV. Si vous utilisez des features avancées (strong consistency, multi-region reads), prévoyez un temps d'analyse supplémentaire.
Alternatives si Workers ne convient pas
Si votre architecture n'est pas adaptée à Workers (fonctions longues, état partagé complexe, dépendances système), les alternatives serverless JavaScript incluent AWS Lambda (Node.js), Vercel Functions, ou Fly.io. Dans le cadre d'un projet nécessitant une plateforme interne sur mesure, l'arbitrage dépend de votre modèle d'exécution et de vos contraintes de souveraineté.
Le runtime Deno : un an de maintenance, puis fin du développement
Un an de corrections de bugs et de sécurité
Le runtime Deno open source — le binaire deno que vous installez localement — continuera de recevoir des correctifs de sécurité et des corrections de bugs pendant un an à compter de l'acquisition. Le développement de nouvelles fonctionnalités s'arrêtera en revanche immédiatement. Après cette période de maintenance, le dépôt restera public et open source, mais Cloudflare ne prévoit pas d'y investir davantage.
Ce que ça signifie pour les projets existants en Deno
Si vous avez des scripts ou des outils internes écrits pour Deno — notamment pour profiter de TypeScript natif sans build step, ou de la sandbox de permissions — vous pouvez les conserver sans urgence immédiate. Deno restera compatible avec les projets existants pendant au moins un an. Au-delà, les options sont :
- Migrer vers Node.js : les deux runtimes ont convergé sur les Web APIs standards. Les APIs Deno natives (
Deno.readFile, etc.) devront être remplacées par leurs équivalents Node ou des shims. - Migrer vers Bun : Bun propose également TypeScript natif sans configuration et supporte un sous-ensemble des APIs Node.js. Il reste plus expérimental.
- Rester sur Deno pendant la fenêtre de maintenance : option raisonnable pour des outils non critiques.
Pour les équipes qui utilisent Deno comme runtime de test ou de scripting dans leur chaîne CI, une migration vers Node.js 22+ ou Bun offre la meilleure continuité à long terme. Si vous avez besoin d'accompagnement sur le choix d'infrastructure pour vos projets d'automatisation, nous pouvons vous aider à évaluer les options.
Implications pour vos projets serverless et edge
Cloudflare Workers s'impose comme la référence edge JavaScript
Avec cette acquisition, Cloudflare consolide sa position de premier plan dans l'écosystème edge JavaScript. L'entreprise avait déjà acquis VoidZero (l'équipe derrière Vite, Vitest et Rolldown) en juin 2026, puis Outerbase (intégration base de données) et Astro (framework web). L'acquisition de Deno complète cet écosystème en unifiant le runtime d'exécution côté serveur.
Pour les équipes qui évaluent une stack serverless en 2026, Cloudflare Workers est désormais le choix le plus cohérent pour les fonctions edge JavaScript : runtime open source (workerd), outillage complet (Wrangler, D1, KV, R2, Queues), écosystème standardisé sur les Web APIs et, maintenant, un moteur d'exécution Rust en cours de consolidation avec celld.
Points de vigilance avant de consolider sur Workers
Cloudflare Workers n'est pas adapté à tous les cas d'usage :
- Durée d'exécution limitée : les Workers ont une limite de temps CPU (50 ms par défaut sur le plan gratuit, configurable sur les plans payants). Les tâches longues nécessitent Durable Objects ou une architecture en queues.
- Modèle stateless strict : pas de système de fichiers, pas de sous-processus, pas de modules natifs. Si votre code Node.js utilise des bindings natifs (
.node), il ne migrera pas directement. - Cold start et cold pool : le cold start V8 Isolates est très faible (< 5 ms), mais certaines libs JavaScript lourdes peuvent dépasser les limites de taille du bundle.
Si vous hésitez entre Workers et une architecture Lambda classique pour votre projet, la décision dépend principalement de la latence cible et du modèle de facturation. Prenez contact avec notre équipe pour un cadrage rapide de votre architecture serverless.
FAQ — Cloudflare rachète Deno : Deno Deploy fermé sous 6 mois, celld intégré dans workerd — faut-il réévaluer votre stack serverless ?
Deno est-il encore utilisable après l'acquisition par Cloudflare ?
Oui, le runtime Deno continuera de fonctionner et de recevoir des correctifs de sécurité pendant un an. Les projets existants peuvent rester en production sans migration urgente. Au-delà de cette période, le dépôt reste open source mais sans développement actif de la part de Cloudflare.
Dois-je migrer mes projets Deno Deploy maintenant ?
Vous devez planifier la migration sous six mois, délai annoncé par Cloudflare pour la fermeture de Deno Deploy. Commencez par inventorier vos fonctions déployées et tester leur compatibilité avec Cloudflare Workers, dont l'API Request/Response est identique. Les utilisateurs payants seront accompagnés par Cloudflare dans le processus.
Qu'est-ce que celld et pourquoi est-ce important pour Cloudflare ?
celld est une implémentation Rust de l'API Cloudflare Workers, publiée par Deno en août 2026. Son intégration dans workerd (le runtime open source de Cloudflare) vise à améliorer la portabilité locale, la fidélité des émulateurs de développement et potentiellement les performances à froid. C'est la principale justification technique de l'acquisition.
Cloudflare Workers peut-il remplacer Node.js pour des applications métier ?
Pour des fonctions stateless légères (APIs, webhooks, proxies, SSR), oui. Pour des applications avec longue durée d'exécution, accès au système de fichiers, dépendances natives ou forte consommation mémoire, Workers impose des contraintes que Node.js (sur un VPS, Lambda ou Fargate) n'a pas. L'arbitrage dépend de vos cas d'usage précis.
Bun est-il une alternative viable à Deno après cette acquisition ?
Bun est une alternative pour le développement local et les scripts, avec TypeScript natif et compatibilité partielle Node.js. Il est en revanche moins mature que Node.js pour la production à grande échelle. Pour l'exécution edge, il n'est pas directement comparable à Cloudflare Workers.