Deno rejoint Cloudflare pour auto-héberger Workers et Durable Objects
Cloudflare intègre l’équipe de Ryan Dahl et fusionne workerd avec celld, l’implémentation ouverte de Workers publiée par Deno en août. Évaluez celld si vous voulez exécuter vos applications Workers sur votre propre infrastructure plutôt que sur le réseau Cloudflare.
9 octobre 2026. Cloudflare annonce que l’équipe Deno, conduite par Ryan Dahl, rejoint l’entreprise pour fusionner le runtime open source workerd avec celld, l’implémentation ouverte des Workers et des Durable Objects publiée par Deno en août 2026. 9 octobre 2026. Kenton Varda, architecte historique des Workers chez Cloudflare, co-signe l’annonce. 9 octobre 2026. The New Stack présente l’opération comme le rachat de la startup de l’inventeur de Node.js. Pourquoi c’est important : le modèle de programmation Workers, jusqu’ici indissociable du réseau Cloudflare, devient exécutable sur votre propre infrastructure — et l’accusation de « lock-in » que Cloudflare traîne depuis des années perd, d’un coup, son argument technique.
celld, le chaînon qui manquait à workerd
workerd est le moteur open source qui exécute les Workers : un runtime JavaScript/Wasm isolé, publié sous licence ouverte. Mais il y a un piège, que Ryan Dahl formule lui-même : le support des Durable Objects dans workerd se limite à une instance unique. Or la puissance de l’abstraction vient précisément de la distribution — un Durable Object par salon de discussion, par file, par état d’application, répartis sur plusieurs machines, avec le placement, le routage et le stockage durable gérés par la plateforme.
celld comble ce vide. C’est un binaire unique, écrit en Rust, dont la seule dépendance de service externe est un object storage. Lancer celld revient à gérer plusieurs instances du binaire et un unique bucket de stockage d’objets. Une application peut alors embarquer calcul, bases relationnelles, files d’attente et canaux temps réel sans déployer un projet d’infrastructure par service. Pour Ryan Dahl, c’est le retour à la simplicité qu’il poursuivait déjà en 2009, quand il présentait Node.js avec un serveur IRC de cinq cents lignes dans un entrepôt berlinois.
Pourquoi Durable Objects change la donne
Un Durable Object ressemble, vu de loin, à un état clé-valeur. Vu de près, c’est autre chose : un singleton distribué doté d’une base SQLite locale, d’un traitement JavaScript mono-thread et de WebSocket qui lui sont directement adressés. Chaque objet est une unité d’état et de logique que l’on peut placer, répliquer et router séparément.
La conséquence pour le développeur est profonde. Dans une architecture trois-tiers classique, l’état vit dans une base partagée et le calcul dans des instances sans état ; faire collaborer deux utilisateurs en temps réel oblige à assembler un pub/sub, un cache et une base — trois systèmes à opérer et à réconcilier. Avec les Durable Objects, le canal et son état vivent dans le même objet : on sharde dès la conception en donnant un objet par salon, par document ou par session, et le reste suit.
C’est cette densité — calcul, état, temps réel et persistance dans une seule abstraction — que celld exporte hors du réseau Cloudflare. Et c’est elle, plus que le runtime lui-même, qui rend l’offre difficile à copier pour les concurrents.
L’accusation de « lock-in » tombe d’elle-même
Depuis des années, une théorie circule : Cloudflare aurait rendu Workers volontairement différent pour enfermer ses clients. Les applications construites sur Durable Objects ne sont pas seulement écrites différemment, elles sont architecturées différemment — donc, disait-on, impossibles à migrer. Sous cette théorie, celld était une menace : une implémentation open source permettant de déplacer ces applications chez un autre fournisseur.
Kenton Varda répond frontalement. Workers est différent, concède-t-il, mais parce qu’il est meilleur : déployer une application sur des centaines de points de présence pour un coût dérisoire, avec des bindings qui sécurisent l’accès aux ressources externes, n’a pas d’équivalent chez les autres hébergeurs. Et le « lock-in » nuirait à Cloudflare, pas l’inverse : si aucune échappatoire n’existait, ses plus gros clients n’auraient jamais signé. L’ouverture de celld change la posture — au lieu de défendre un fossé, Cloudflare ouvre volontairement la porte et parie que son modèle de programmation gagnera sur le fond.
Une bataille de modèles de programmation, pas de parts de marché
L’enjeu dépasse Cloudflare. Le marché de l’edge computing s’est longtemps joué sur le runtime : chacun — Vercel, Netlify, Fly.io, Deno Deploy — proposait sa variante de « fonctions serverless en périphérie ». Cloudflare a choisi un autre terrain, celui du modèle de programmation : les Durable Objects ne sont pas une fonction de plus, mais une façon différente de concevoir l’application, où l’état et le calcul vivent au même endroit.
En ouvrant ce modèle, Cloudflare fait un pari risqué mais cohérent : si le modèle Workers devient un standard que l’on peut exécuter partout, la valeur se déplace du réseau vers l’écosystème, les outils et le savoir-faire. C’est exactement la stratégie qu’Amazon a gagnée avec AWS, ou que Google a tentée avec Kubernetes : gagner sur le standard, et monétiser autour. La différence, ici, est que le standard en question était jusqu’ici la propriété privée de Cloudflare.
Ce que ça change pour l’auto-hébergement
Concrètement, fusionner workerd et celld vise un objectif unique : rendre le modèle Workers « radicalement simple à construire et à opérer sur votre propre infrastructure ». Les cas d’usage ne manquent pas — souveraineté des données, déploiement on-premise, environnements de développement locaux fidèles à la production, ou simple préférence pour l’auto-hébergement.
Le point de bascule se joue sur les Durable Objects. Chaque Durable Object est un petit serveur adressable individuellement, doté de sa propre base SQLite, avec une exécution JavaScript mono-thread facile à raisonner et un accès synchrone à sa base locale. C’est l’abstraction qui permet de sharder données et connexions WebSocket dès la conception — et c’est elle que celld rend enfin distribuable hors de Cloudflare. L’expérience Deno Deploy a d’ailleurs enseigné à Ryan Dahl la complexité qu’il fallait fuir : plusieurs clouds publics, plusieurs bases, des services profondément enchevêtrés. celld en est l’antidote.
Prenez l’exemple d’une équipe qui construit une application de collaboration temps réel. Aujourd’hui, elle doit choisir entre deux mondes : déployer sur le réseau Cloudflare et hériter des Durable Objects, ou rester sur sa propre infrastructure et reconstruire à la main pub/sub, state et persistance. La fusion workerd/celld promet de supprimer ce choix, en laissant la même application tourner indifféremment sur Cloudflare ou sur un cluster auto-hébergé derrière un unique bucket de stockage d’objets.
Ce que l’opération ne change pas
L’annonce ne signe pas la disparition de Deno. Le runtime Deno continue d’exister et d’évoluer — Ryan Dahl renvoie vers le blog Deno pour le détail du sort du runtime et des efforts de l’équipe. Pour l’utilisateur de Deno Deploy, rien n’est annoncé comme un arrêt immédiat ; mais l’orientation stratégique se lit sans ambiguïté : l’énergie de l’équipe se concentre désormais sur la convergence workerd/celld au sein de Cloudflare.
Reste une inconnue classique de ce type de rapprochement : le calendrier. Aucune date de disponibilité générale n’est donnée pour la fusion. celld, publié en août 2026, est encore jeune ; la convergence de deux runtimes, même voisins, est un chantier de plusieurs mois. La prudence s’impose pour quiconque voudrait bâtir sa production dessus dès maintenant.
Verdict
Si vous développez sur Workers et redoutez la dépendance à Cloudflare, suivez la fusion workerd/celld : c’est la première vraie porte de sortie vers l’auto-hébergement, mais elle n’est pas encore mûre pour la production. Si vous opérez votre propre infrastructure et que le modèle Durable Objects vous parle, évaluez celld en environnement de test — c’est aujourd’hui la voie la plus crédible pour obtenir des Durable Objects distribués sans le réseau Cloudflare. Si vous êtes sur Deno Deploy, ne changez rien dans l’immédiat, mais anticipez : la trajectoire de l’équipe pointe vers Cloudflare, et vos choix d’architecture à moyen terme devraient en tenir compte.