Aller au contenu

Le média des artisans du web dimanche 11 octobre 2026

DevOps & serveurs

Deno rejoint Cloudflare, Deno Deploy fermera dans six mois

Toute l'équipe Deno rejoint Cloudflare, qui fermera Deno Deploy dans six mois et limitera la maintenance du runtime open source à un an. JSR et la bibliothèque rusty_v8 survivent au changement, migrés vers l'infrastructure de Cloudflare.

Illustration Deno rejoint Cloudflare

Ryan Dahl, créateur du runtime Deno, a annoncé le 9 octobre 2026 que toute son équipe rejoint Cloudflare. L’opération combine le travail de Deno avec celui des équipes Workers et Durable Objects, et marque la fin de Deno comme runtime et hébergeur indépendant. Pour les développeurs qui ont déployé des applications sur Deno Deploy, l’annonce impose une migration à horizon fixe plutôt qu’une simple mise à jour technique.

Un calendrier de fermeture précis

Deno Deploy, le service d’hébergement serverless de l’éditeur, continuera de fonctionner pendant six mois avant sa fermeture, avec un accompagnement à la migration vers Cloudflare Workers pour les clients payants. Le runtime open source, lui, survit plus longtemps mais pas indéfiniment : Cloudflare publiera des versions mensuelles pendant un an, limitées aux correctifs de sécurité et de bugs, avant l’arrêt officiel du développement. Le code reste open source et peut être repris par quiconque souhaite poursuivre le projet.

ComposantDevenirÉchéance
Deno Deploy (hébergement)Fermeture, migration accompagnée vers Workers pour les clients payants6 mois
Runtime Deno (open source)Versions mensuelles, correctifs de sécurité et bugs uniquement1 an, puis arrêt du développement
JSR (registre de paquets)Continue de fonctionner, infrastructure transférée chez CloudflarePas de date d’arrêt annoncée
rusty_v8Maintenu par Cloudflare, cible une intégration dans workerdPas de calendrier précisé

Ce que ça change pour un déploiement en cours

Un projet hébergé sur Deno Deploy aujourd’hui continue de fonctionner sans interruption immédiate, mais la fenêtre de six mois est courte à l’échelle d’une migration d’infrastructure. La bascule vers Cloudflare Workers demande d’adapter la configuration de déploiement, pas seulement de changer de registre DNS :

# Déploiement historique sur Deno Deploy (CLI deployctl)
deployctl deploy --project=mon-projet main.ts

# Équivalent côté Cloudflare Workers, une fois le projet migré
npx wrangler deploy

Les équipes dont l’architecture repose sur des API spécifiques à Deno Deploy (KV intégré, cron Deno Deploy, variables d’environnement propriétaires) ont un travail de portage réel à prévoir, pas une simple redirection d’URL. Un audit des dépendances à l’infrastructure Deno Deploy mérite d’être lancé dès maintenant, avant que la fenêtre de six mois ne se resserre.

Deno Deploy fermera dans six mois ; le runtime open source, lui, n’a plus qu’un an de maintenance avant l’arrêt officiel de son développement.

Un troisième runtime qui sort de la course en tant que produit autonome

Deno s’était positionné depuis 2018 comme l’alternative sécurisée à Node.js, avant que Bun ne vienne occuper le même terrain avec un argument de performance. Avec cette absorption, deux des trois runtimes JavaScript modernes concurrents de Node.js restent en course de façon autonome : Bun d’un côté, et le socle technique de Deno de l’autre, désormais intégré à une plateforme edge plutôt que vendu comme produit distinct. Sur Hacker News et Lobste.rs, la discussion porte moins sur la technique que sur la lecture du mouvement : consolidation du marché serverless autour de Cloudflare plutôt que continuité réelle du projet Deno. Pour qui envisageait de miser sur Deno Deploy précisément pour son indépendance par rapport aux géants du cloud, l’argument perd de sa force. Des alternatives comme les fonctions edge basées sur des micro-VM Firecracker restent disponibles pour qui cherche un hébergement serverless hors de l’écosystème Cloudflare.

Que faire en attendant

Pour un projet encore en développement, le plus simple reste d’attendre les instructions de migration promises aux clients payants avant d’agir dans l’urgence. Pour un site déjà en production sur Deno Deploy, un inventaire des outils en ligne de commande et des dépendances propres à la plateforme permet de chiffrer l’effort de bascule avant que l’échéance n’arrive. Les équipes qui préfèrent reprendre la main plutôt que suivre un fournisseur peuvent aussi regarder du côté de l’auto-hébergement, une option qui évite de revivre ce type de bascule forcée.

Ce qu’il faut retenir

L’équipe Deno rejoint Cloudflare, Deno Deploy ferme dans six mois et le runtime open source n’a plus qu’un an de maintenance avant l’arrêt de son développement actif. JSR et rusty_v8 survivent, intégrés à l’infrastructure Cloudflare. Toute application hébergée sur Deno Deploy doit entamer sans attendre l’inventaire de ses dépendances à la plateforme.

Je vois dans cette opération la confirmation d’un risque connu mais souvent sous-estimé : un hébergement serverless gratuit ou bon marché adossé à un seul éditeur reste une dépendance, pas un acquis. Les clients de Deno Deploy ont six mois pour s’en souvenir ; les autres ont intérêt à vérifier dès maintenant la portabilité réelle de leur propre pile avant la prochaine annonce de ce genre — Simon Janvier.

Pour aller plus loin : l’annonce officielle sur le blog de Deno.

Partager LinkedIn Bluesky Hacker News E-mail

À lire aussi