Cloudflare rachète Deno et mettra fin au développement du runtime dans un an

Cloudflare rachète Deno en entier. La société maintiendra le runtime Deno pendant un an de plus, avec des versions mensuelles qui corrigeront des bugs et apporteront des mises à jour de sécurité. Passé ce délai, Cloudflare cessera de le développer. Le code restera ouvert, et l'entreprise invite explicitement ceux qui le souhaitent à poursuivre le projet. L'opération a été annoncée le 9 octobre 2026. D'après les déclarations des deux parties, son principal actif n'est pas le runtime lui-même, mais celld, que l'équipe de Deno a publié en août.

Ce que Cloudflare obtient réellement

celld est une implémentation open source du pattern Durable Objects de Cloudflare Workers. Selon Ryan Dahl, créateur de Deno et de Node.js, le système fonctionne « étonnamment bien » et s'appuie uniquement sur le stockage objet pour la coordination et la persistance. Il le décrit comme un nouveau modèle de développement côté serveur, et non comme une énième API pour le système de fichiers ou le réseau.

Cloudflare formule ainsi son objectif : faire du self-hosting de workerd un moyen pleinement pris en charge de créer et d'exécuter des applications selon le modèle de programmation Workers. Pour une plateforme dont le modèle vivait jusqu'ici surtout au sein de sa propre infrastructure, c'est un pas vers la portabilité. L'équipe de Deno, qui a déjà construit un équivalent ouvert fonctionnel, règle cette question plus vite qu'un développement interne partant de zéro.

Pourquoi le runtime ne sera pas poursuivi

Sur Hacker News, Dahl a qualifié la décision de conjointe et a dit y adhérer. À son avis, Deno est bien conçu et contient de bonnes idées, mais il ne résout pas de problèmes vraiment importants. Le projet a été happé par le « puits gravitationnel » de la compatibilité avec Node, qui l'oblige à se comporter exactement comme Node. Sa question est directe : pourquoi réécrire Node si Node fonctionne ? De petits gains de performance, d'ergonomie ou de sécurité ne suffisent pas pour cela.

C'est une franchise rare de la part du créateur d'un projet : il reconnaît lui-même que la principale valeur de Deno quitte le runtime pour se loger dans une autre idée d'architecture.

Les faits clés de l'opération :

• Format : Cloudflare rachète Deno en totalité.
• Maintenance du runtime : 12 mois, avec des versions mensuelles.
• Contenu des versions : corrections de bugs et mises à jour de sécurité, aucune nouvelle fonctionnalité n'est promise.
• Licence : Deno reste un projet ouvert, les forks et la poursuite du développement par la communauté sont les bienvenus.
• Actif principal : celld, dont la première version est sortie en août 2026.
• À titre de comparaison : les permissions sont apparues dans Node.js dans la v20.0.0 en avril 2023 et sont devenues stables dans la v22.13.0 en janvier 2025.

Permissions : ce qui se perd

Simon Willison, auteur de la note, cite le système de permissions comme sa fonctionnalité préférée de Deno. Un script s'exécute avec une liste précise de fichiers et de dossiers qu'il peut lire et écrire, ainsi que des hôtes réseau auxquels il a le droit d'accéder. Node.js propose un modèle similaire, mais avec une limite importante : la liste blanche d'hôtes précis n'est pas prise en charge, le réseau est soit activé, soit désactivé.

Pour ceux qui exécutent du code non fiable, y compris du code généré par des modèles, cette différence compte. Le contrôle granulaire de l'accès réseau reste un avantage de Deno. Une fois le runtime abandonné, il faudra soit le chercher dans des forks, soit le compenser par d'autres moyens d'isolation.

Que faire pour les équipes sous Deno

Un an de maintenance laisse une fenêtre correcte pour planifier, mais ce n'est pas une raison de repousser la décision. Vérifiez dans quelle mesure votre code dépend d'API spécifiques à Deno, plutôt que de standards web communs et de la compatibilité avec Node. Plus la compatibilité est élevée, moins la migration coûtera cher. Si les permissions au niveau des hôtes sont critiques pour vous, évaluez dès maintenant les alternatives : un sandbox au niveau du conteneur ou du processus, ou un futur fork.

Il faudra aussi suivre de près celld et la façon dont Cloudflare formalisera la prise en charge du self-hosting de workerd. Si la promesse se concrétise, le modèle Workers pourra tourner en dehors du cloud de Cloudflare. Pour les équipes qui redoutent la dépendance à un fournisseur, ce sera un argument de poids.