Cloudflare rachète Deno pour rendre Workers auto-hébergeable

Le vendredi 9 octobre 2026, Cloudflare a annoncé le rachat de Deno, la jeune pousse derrière le runtime JavaScript et TypeScript Deno, et l'arrivée de toute l'équipe Deno dans l'entreprise. La nouvelle est venue d'un billet commun de Ryan Dahl, cofondateur de Deno et créateur de Node.js, et de Kenton Varda, ingénieur principal de Cloudflare pour Workers, publié sur le blog de Cloudflare. Dahl a écrit une note similaire sur le blog de Deno. Les termes financiers n'ont pas été divulgués.

À lire aussi: Jellyfin 12.0 abandonne le préfixe 10, refond sa bibliothèque et change d'apparence · Project Zenith de Microsoft veut rendre Windows « prêt à coder ». Les développeurs ne sont pas convaincus.

L'opération place l'un des runtimes indépendants les plus connus à l'intérieur de la plateforme avec laquelle il a rivalisé pendant des années. Deno a été lancé comme une réécriture des idées derrière Node.js : sécurisé par défaut, avec TypeScript intégré et une bibliothèque standard fournie d'emblée. Cloudflare Workers exécute du JavaScript sur le réseau de périphérie de l'entreprise plutôt que sur un serveur que le développeur possède. Les personnes qui ont bâti l'alternative travailleront désormais sur le runtime de Cloudflare. TechCrunch a présenté le rachat comme une tentative d'améliorer le modèle de programmation de Workers.

Deno avait levé 26 millions de dollars au total, dont une série A menée par Sequoia, selon la couverture de TechCrunch en 2022. C'était une petite entreprise pour les standards du cloud, et elle n'a jamais transformé la bienveillance des développeurs à son égard en une grande activité d'hébergement. Son produit hébergé, Deno Deploy, concurrençait directement Workers et d'autres plateformes de périphérie.

Ce qu'il advient du runtime et de son service d'hébergement

Le runtime survit, avec un compte à rebours. Cloudflare a indiqué qu'elle maintiendrait le runtime Deno avec environ 12 mois de correctifs de bogues et de sécurité, puis qu'elle mettrait fin à son propre développement. Cela ne ferme pas le code. Le projet reste open source, et n'importe qui peut continuer à s'appuyer sur lui après l'arrêt de Cloudflare. Mais une branche maintenue avec une date de fin connue n'est pas la même chose qu'une branche activement développée. Les équipes qui ont mis en production sur Deno ont désormais une raison de planifier une sortie, ou de maintenir elles-mêmes un fork.

Deno Deploy, le service hébergé, fermera. Le billet de Cloudflare décrit le recentrage de l'équipe sur Workers sans fixer de date, et des médias tiers situent l'arrêt à environ six mois, ce qui le placerait vers avril 2027. Dans un cas comme dans l'autre, le versant commercial de Deno s'achève tandis que le versant open source se poursuit.

Cette séparation est le cœur de l'opération. Cloudflare n'achète pas une activité d'hébergement pour la faire tourner à côté de la sienne. Elle achète une équipe et intègre son travail à Workers, et elle dit explicitement que les produits autonomes avaient atteint leurs limites.

Pourquoi Cloudflare dit avoir conclu l'opération

Varda a présenté le rachat comme une réponse au problème de l'enfermement propriétaire. Il a écrit qu'une « théorie répandue » veut que Cloudflare « ait fait fonctionner Cloudflare Workers différemment des autres plateformes cloud afin de créer de l'enfermement », et a soutenu le contraire : « être open source et offrir une porte de sortie aux gens, c'est une bonne affaire. » Son argument est que laisser les clients partir fait partie de ce qui les rend disposés à rester.

Cet argument ne fonctionne que s'il existe un endroit où aller. Le catalyseur a été celld, une implémentation open source qui exécute des applications Workers, y compris les Durable Objects, sur la machine d'un développeur. Elle est livrée sous forme d'un unique binaire Rust sous licence Apache-2.0. Varda a dit que l'équipe Cloudflare s'était réjouie lorsque Deno l'a publiée en août : « quand l'équipe Deno a publié celld en août, nous nous sommes réjouis. »

Les Durable Objects sont la partie à état de la plateforme Workers, et selon The New Stack, leur prise en charge par workerd s'était limitée à une seule instance. C'était suffisant pour des tests locaux, mais pas pour un auto-hébergement à l'échelle, et combler cet écart est précisément ce que celld a été conçu pour faire.

Pourquoi l'auto-hébergement est le vrai sujet

L'auto-hébergement est le terme auquel Cloudflare revient sans cesse, et c'est la partie de l'annonce aux conséquences les plus durables. Workers est un service géré : les développeurs téléversent du code et Cloudflare l'exécute, ce qui rend la plateforme pratique et rend aussi son abandon coûteux. Exécuter le même code ailleurs a impliqué de le réécrire, car Workers diffère des autres plateformes sans serveur d'une manière qui touche à la structure même des applications. celld a montré que la différence n'est pas fondamentale. Il exécute des applications Workers, Durable Objects inclus, sur du matériel que le développeur contrôle, ce qui est la preuve dont Cloudflare avait besoin que son runtime peut voyager.

Cette preuve compte pour Cloudflare parce que l'enfermement est une critique constante faite aux plateformes de périphérie, et elle compte pour les développeurs parce que le choix entre praticité et portabilité est généralement à faire tôt, avant de savoir comment le projet grandira. Si workerd devient auto-hébergeable en tant que fonctionnalité prise en charge, le même code pourra tourner dans un petit déploiement et sur le réseau de Cloudflare, et la décision d'utiliser Workers commencera à paraître réversible.

Ce que cela signifie pour les utilisateurs de Deno

Pour quiconque exécute Deno aujourd'hui, l'annonce fixe un calendrier plutôt qu'une fin. Le runtime continue de recevoir des correctifs de sécurité pendant environ un an, ce qui couvre le risque immédiat qu'une vulnérabilité connue reste non corrigée. Ce qui n'est pas couvert, c'est tout le reste qui rend un runtime digne d'être choisi : nouvelles API, travail sur les performances et le flux constant de correctifs qui gardent un runtime de langage utilisable face à un écosystème en évolution.

La conception de Deno adoucit l'atterrissage. Le projet est livré avec une bibliothèque standard et un ensemble d'API aux standards du web, de sorte que les projets bâtis dessus ne sont pas enfermés dans un cadre propriétaire. Une grande partie de ce code tourne déjà sur d'autres runtimes, et les utilisateurs de Deno Deploy peuvent migrer vers Workers ou vers un autre hébergeur de périphérie. La migration est un travail plutôt qu'une réécriture complète, ce qui sépare la gêne de la crise.

Un runtime open source sous un seul fournisseur

Le plan de Varda est précis. Dahl et le cofondateur de Deno Bert Belder dirigeront un nouvel effort pour faire de workerd, le runtime Workers open source de Cloudflare, un moyen pleinement pris en charge de créer et d'exécuter des applications Workers. Le travail fusionnera le code et les idées de celld dans workerd. Du point de vue d'un développeur, c'est là la substance de l'opération : la porte de sortie passe d'une expérience tierce au runtime principal.

Dahl a formulé l'ambition sans détour. « Nous rejoignons Cloudflare pour faire du modèle de programmation de Workers un moyen grand public de bâtir des serveurs », a-t-il écrit.

« Nous rejoignons Cloudflare pour faire du modèle de programmation de Workers un moyen grand public de bâtir des serveurs. » — Ryan Dahl, cofondateur de Deno

La promesse open source pèse dans la présentation de Cloudflare, il est donc utile de préciser ce qu'elle recouvre. workerd est déjà open source, et Cloudflare affirme que le chemin d'auto-hébergement fusionné le sera aussi. Mais exécuter la plateforme de Cloudflare sur son propre matériel n'est pas la même chose qu'une plateforme indépendante. Cela réduit le risque de rester bloqué ; cela ne rétablit pas Deno comme concurrent.

Une habitude d'acheter des outils pour développeurs

Deno est le troisième rachat d'outils pour développeurs annoncé par Cloudflare en 2026, a relevé The New Stack. En janvier, elle a acheté Astro, le cadre web. En juin, elle a acheté VoidZero, l'équipe derrière Vite, Vitest, Rolldown et Oxc. En octobre, elle a acheté Deno. Les trois partagent une même forme : de petites équipes à l'influence démesurée sur la manière dont les développeurs JavaScript construisent, absorbées par une entreprise qui veut ce public sur sa plateforme.

C'est ce schéma qui fait lire l'opération Deno comme une stratégie plutôt qu'un sauvetage. Le cœur de métier de Cloudflare est de vendre un réseau, et Workers est sa manière de vendre du calcul sur ce réseau. Posséder la chaîne d'outils que les développeurs saisissent en premier donne à Cloudflare un mot à dire sur les réglages par défaut. Astro, Vite et désormais Deno se situent tous tôt dans la vie d'un projet, au moment où les choix se font et les habitudes se prennent. Acheter les mainteneurs est un chemin moins coûteux vers cette influence que tenter de les déloger.

Tous les développeurs ne liront pas l'opération ainsi. Le runtime que les utilisateurs de Deno ont choisi est désormais contrôlé par Cloudflare, et c'est Cloudflare qui décidera à quoi ressemblera la prochaine version. L'open source règle la question de la licence, pas celle de la gouvernance : qui définit la feuille de route, quels correctifs sont intégrés et quel comportement compte comme un bogue.

Réserves

Certains aspects de l'affaire sont fermes, d'autres non. Le rachat lui-même, l'arrivée de l'équipe, la fenêtre de maintenance d'environ 12 mois et le statut open source du runtime proviennent tous du billet de Cloudflare. Les dates de fin précises, y compris celle de la fermeture de Deno Deploy, proviennent de médias tiers plutôt que de Cloudflare, qui décrit la direction sans s'engager sur chaque date.

Le prix est inconnu, il est donc impossible de juger si les investisseurs de Deno, dont Sequoia, ont gagné de l'argent dans la vente. Le travail d'auto-hébergement est décrit comme un effort à venir, non comme une fonctionnalité livrée. Cloudflare a dit qu'elle aurait d'autres annonces dans les mois à venir, une promesse sans date.

Il existe aussi un écart entre le sort du runtime et les besoins de ses utilisateurs. Douze mois de correctifs maintiennent les applications Deno existantes en fonctionnement à court terme. Cela ne finance pas de nouvelles fonctionnalités et ne répond pas à la question des bogues et des problèmes de sécurité qui apparaîtront après la fermeture de la fenêtre. Un fork communautaire est possible, mais savoir si quelqu'un le financera est une question distincte de celle de savoir si quelqu'un le souhaite.

À suivre

Le signal le plus clair sera de savoir quand, et si, workerd devient auto-hébergeable comme chemin pris en charge. Si Cloudflare le livre, la lignée de travail celld devient une véritable porte de sortie et l'argument contre l'enfermement aura de quoi s'appuyer. Si l'effort reste interne ou prend du retard, le rachat ressemblera davantage à une acquisition de talents avec un vernis open source.

Le deuxième signal est la dernière année du runtime. Observez quelle maintenance le projet reçoit réellement, et si la communauté organise un successeur avant la fin de la fenêtre. Le troisième est ce que Cloudflare achètera ensuite. Trois rachats d'outils pour développeurs en un an constituent une direction, et la prochaine annonce montrera si Deno était la fin de la séquence ou une étape de plus.

Pour l'heure, le fait le plus clair est celui énoncé en premier par Cloudflare : l'équipe Deno rejoint l'entreprise qui a bâti le runtime que Deno était censé améliorer.

Image de couverture : HaeB, Wikimedia Commons, CC BY-SA 4.0.