Andy Garcia · dev freelance
FRENES
Retour au blog
Open source

Cloudflare récupère l'équipe Deno. Deno Deploy a six mois, et le runtime Deno un an de correctifs

19 octobre 2026 6 min de lecture

Le vendredi 9 octobre 2026, Ryan Dahl, qui a créé Node.js puis Deno, a annoncé que toute l'équipe de Deno rejoint Cloudflare. Son billet sur le blog de Deno dit ce que cela signifie en quatre lignes. Le runtime Deno bénéficie encore d'un an de versions mensuelles avec correctifs de bugs et mises à jour de sécurité, puis l'équipe arrête son développement ; il reste open source, et d'autres sont invités à le poursuivre. Deno Deploy, le service d'hébergement, continue de fonctionner six mois puis ferme, avec un accompagnement de migration pour les clients payants vers Cloudflare Workers. JSR, le registre de paquets, continue de tourner, sur une infrastructure qui passe chez Cloudflare. Et rusty_v8 reste maintenu, avec un travail pour l'intégrer à workerd, le runtime Workers open source de Cloudflare.

Le même jour, Dahl et Kenton Varda, de Cloudflare, ont publié un billet commun sur le blog de Cloudflare. workerd et celld, la version auto-hébergée de Workers imaginée par Deno, sont en cours de fusion, et Dahl et Bert Belder dirigeront l'effort pour faire de l'auto-hébergement de workerd « une façon de premier rang, officiellement prise en charge » d'exécuter des applications sur le modèle Workers. Aucun des deux billets n'emploie le mot acquisition ni ne cite un prix. The New Stack a décrit l'opération comme un rachat de la startup par Cloudflare et a rapporté que les conditions n'étaient pas divulguées.

J'orchestre mon travail dans Claude Code, qui est livré sous forme d'exécutable Bun, donc ce qui arrive à un runtime JavaScript quand son entreprise change de mains n'est pas une question abstraite pour moi. J'ai lu les deux billets, la page de tarifs de Deno Deploy, la documentation de migration et l'historique des versions. Les horloges sont claires. Les données ne sont pas mentionnées.

Ce que Cloudflare récupère

L'actif de cette histoire, c'est celld. Deno a publié sa première version sur GitHub, la v0.1.0, le 5 août. C'est un démon écrit en Rust qui exécute une application Cloudflare Workers sur tes propres machines, à partir du wrangler.json que tu as déjà : Workers, Durable Objects, KV, Queues, D1, R2, Workflows et Cron Triggers. Son état à long terme vit dans un bucket compatible S3, Google Cloud Storage ou Azure. La licence est Apache 2.0.

Cela comble un manque que Varda admet dans sa moitié du billet. Cloudflare a ouvert le code de workerd après avoir proposé Workers for Platforms à des clients comme Shopify en 2022, mais ses Durable Objects s'exécutent « seulement en instance unique, suffisant pour les tests locaux, mais incapable de monter en charge ». Le routage de production de Cloudflare est, selon ses mots, « une bête » dont aucun auto-hébergeur ne voudrait. Il a expliqué à The New Stack pourquoi la correction compte pour Cloudflare : « Si le modèle nous est exclusif, cela réduit notre TAM [marché adressable total] et nous rend en fin de compte moins compétitifs face aux clouds historiques. »

Le runtime Deno ne fait pas partie de ce plan, et Dahl ne fait pas semblant du contraire. Dans un commentaire Hacker News cité par Simon Willison, il a écrit que Deno « a été aspiré dans le puits gravitationnel de la compatibilité Node, qui le force à se comporter exactement comme Node. Pourquoi réimplémenter Node ? Ça marche. »

Deux runtimes, deux acheteurs

Le 2 décembre 2025, Bun a annoncé avoir été racheté par Anthropic. Son billet promettait que Bun reste sous licence MIT et « extrêmement activement maintenu », et en donnait la raison en deux phrases : « Claude Code est livré sous forme d'exécutable Bun à des millions d'utilisateurs. Si Bun casse, Claude Code casse. »

Le runtime de Deno est lui aussi sous licence MIT ; le fichier de licence du dépôt le dit toujours. La licence n'a pas prédit la différence entre les deux issues. Ce qui l'a prédite, c'est de savoir si l'acheteur livre son propre produit sur le runtime. Anthropic livre Claude Code sur Bun. La plateforme Workers de Cloudflare tourne sur workerd.

En septembre, j'ai écrit sur DuckDB, dont les créateurs ont vendu leur entreprise à Amazon tandis que la licence et une fondation à but non lucratif distincte restaient là où elles étaient. Deno est la version de cette histoire où les gens partent et où le code reste derrière, avec une date de fin publique pour sa maintenance.

Les horloges, avec des dates

Deno Deploy dans sa forme actuelle est devenu disponible en version générale le 3 février 2026, sous la promesse « Pas d'adaptateurs. Pas de configuration de build. Pas de fichiers de configuration propres à un fournisseur. » Le 19 octobre, la documentation de Deno contenait encore le guide pour y migrer depuis Deploy Classic, qui devait fermer, avec l'API de subhosting v1, le 20 juillet 2026. Ce guide prévenait que les données KV existantes n'étaient pas migrées automatiquement et que les files Deno n'étaient pas prises en charge sur la nouvelle plateforme.

Les équipes qui ont quitté Deploy Classic cet été font maintenant face à une deuxième migration. L'annonce ne donne aucune date calendaire pour la fermeture. Six mois après le 9 octobre, cela tombe vers le 9 avril 2027. L'année du runtime court jusqu'à environ octobre 2027.

L'historique des versions montre ce que « mensuel » veut dire. Deno a publié huit versions sur GitHub en douze semaines, de la 2.9.0 le 25 juin à la 2.9.7 le 17 septembre. Au moment où j'écris, le 19 octobre, la 2.9.7 est toujours le dernier tag. Une version par mois, correctifs et sécurité seulement, c'est de la maintenance, pas du développement.

L'arithmétique du déménagement

La facture d'hébergement n'est pas l'obstacle. Prends une application qui sert 8 millions de requêtes par mois à 7 millisecondes de CPU chacune, le chiffre par requête que Cloudflare utilise dans ses propres exemples de tarification.

Sur Deno Deploy Pro, 20 $ par mois incluent 5 millions de requêtes, puis 2 $ par million : 20 $ + 3 × 2 $ = 26 $. Le CPU est de 8 millions × 7 ms = 56 millions de ms, environ 15,6 heures, dans les 50 heures incluses, en supposant que le temps mémoire reste lui aussi dans son quota.

Sur Workers Paid, le minimum mensuel de 5 $ inclut 10 millions de requêtes et 30 millions de millisecondes de CPU, puis 0,02 $ par million de millisecondes de CPU supplémentaire. Le CPU au-dessus du quota est de 56 millions moins 30 millions, soit 26 millions de ms, donc 26 × 0,02 $ = 0,52 $. Total 5,52 $, et Cloudflare ne facture pas la sortie de données.

Sur les seules requêtes et le CPU, la destination est moins chère. KV, le stockage et, sur Workers, les Durable Objects sont facturés à part, donc prends ceci comme un plancher, pas comme un devis. Le vrai coût, c'est le code. Un gestionnaire de requêtes écrit en TypeScript se porte en grande partie. Deno.openKv, Deno.cron et les méthodes de file KV sont des API Deno ; sur Workers, les équivalents (bindings KV et Queues, Cron Triggers) se déclarent dans la configuration et ont leurs propres interfaces. Et l'accompagnement de migration est promis aux clients payants. Le billet du 9 octobre ne dit rien des applications du forfait gratuit, jusqu'à 1 million de requêtes par mois.

Ce que je ferais ce mois-ci

Si j'avais une application Deno en production, cinq choses, dans cet ordre.

Inventorie les appels propres à Deno. Cherche dans le code Deno.openKv, Deno.cron, enqueue et listenQueue, le SDK @deno/sandbox et tout script deployctl. Chaque occurrence est un point de migration. Tout le reste, c'est du TypeScript.

Exporte les données KV tant que le service répond. La documentation de Deno décrit comment ouvrir une base KV managée depuis une application CLI Deno locale avec l'identifiant de la base et un jeton d'accès dans DENO_KV_ACCESS_TOKEN. Un court script qui liste chaque clé dans un fichier que tu contrôles vaut mieux qu'un ticket de migration ouvert en mars. La même page dit que les données KV sont stockées aux États-Unis, avec sa région principale en Virginie du Nord (us-east4), ce qui vaut la peine d'être su avant qu'un client ne pose la question.

Fixe ta propre date, plus tôt que la leur. Fin mars 2027 pour Deploy. Pour le runtime, décide d'ici le printemps si tu passes à Node, à Bun ou à un fork communautaire. Si les drapeaux de permissions de Deno étaient la raison de ton choix, le modèle de permissions de Node a été ajouté en v20.0.0 et déclaré stable en v23.5.0 et v22.13.0 ; Simon Willison note qu'il ne peut pas encore autoriser des hôtes réseau précis.

Choisis la destination selon l'endroit où vont les données, pas selon la facture. Workers avec l'aide à la migration de Cloudflare, une flotte auto-hébergée sur celld ou workerd, ou un hébergeur générique qui exécute un runtime standard. Si tu choisis Workers, garde celld en tête comme chemin de sortie. L'argument de Varda lui-même est que le runtime ouvert est la porte de secours, et il écrit que Cloudflare a d'anciens clients qui sont partis ainsi.

Ajoute une question à ta due diligence fournisseur. En tant que CTO, c'est celle que je poserais désormais sur chaque runtime et chaque hébergeur sous un produit : qui paie les personnes qui le maintiennent, et livrent-elles leur propre produit dessus ? Une licence te dit que le code survivra. La réponse à cette question te dit si quelqu'un sera payé pour qu'il continue de fonctionner.

Deno survivra à l'intérêt de son entreprise pour lui. Prépare l'année intermédiaire.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons