Cloudflare prende Deno. Il software resta aperto, ma il suo futuro cambia proprietario

Cloudflare acquisisce Deno e cambia il futuro di uno dei progetti più conosciuti del mondo JavaScript. Il 9 ottobre 2026 Ryan Dahl, creatore di Node.js e cofondatore di Deno, ha annunciato che l’intera squadra entrerà in Cloudflare per lavorare sulla piattaforma Workers. La notizia sembra un normale rafforzamento delle competenze tecniche. I dettagli raccontano qualcosa di più: Deno Deploy sarà chiuso dopo sei mesi e il runtime Deno riceverà ancora un anno di manutenzione, prima che il gruppo smetta di svilupparlo direttamente.

Un programma può continuare a essere open source e perdere comunque il team che lo ha guidato. Una piattaforma può promettere maggiore portabilità mentre diventa il nuovo punto di riferimento di chi scrive software. È qui che l’operazione diventa interessante anche per chi non programma: non riguarda soltanto il linguaggio con cui funzionano i siti, ma il controllo dell’infrastruttura che permette loro di esistere.

Gli annunci congiunti di Cloudflare e quello pubblicato da Deno chiariscono la direzione del progetto e le conseguenze per gli utenti. I termini finanziari dell’operazione non sono stati resi pubblici. Sono invece dichiarati tempi e priorità, ed è su questi che si misura la distanza fra la promessa di un web più aperto e le scelte concrete che dovranno affrontare gli sviluppatori.

Cloudflare e Deno: che cosa cambia dopo l’accordo del 9 ottobre

Deno è un ambiente di esecuzione, o runtime, per JavaScript e TypeScript: in termini semplici, un programma che permette di far funzionare codice anche sul server, al di fuori del browser. Dahl aveva già creato Node.js, diventato un pilastro del web moderno, e con Deno aveva cercato di correggerne alcuni compromessi: gestione più semplice delle dipendenze, strumenti integrati e autorizzazioni più esplicite per accedere alle risorse del sistema.

Nel tempo il progetto ha costruito un proprio ecosistema: il runtime, il servizio di hosting Deno Deploy, il registro di pacchetti JSR e iniziative per avvicinare l’esecuzione del software alle infrastrutture distribuite. L’accordo con Cloudflare non trasferisce soltanto persone: sposta la priorità verso un modello condiviso, basato su Workers e Durable Objects, che dovrebbe poter funzionare sulla rete Cloudflare e anche su sistemi gestiti direttamente da altri.

Cloudflare non ha annunciato che ogni programma Deno smetterà di funzionare. Ha invece indicato, insieme a Dahl, una nuova direzione che ridimensiona lo sviluppo autonomo del runtime e chiude il servizio Deploy secondo una scadenza pubblica. Confondere queste due cose significherebbe attribuire all’annuncio conseguenze che oggi non sono dimostrate.

Deno Deploy chiude dopo sei mesi: che cosa devono sapere gli utenti

La decisione più immediata riguarda Deno Deploy, il servizio commerciale con cui gli sviluppatori pubblicano applicazioni senza dover gestire direttamente i server. Deno ha comunicato che il servizio resterà operativo per altri sei mesi a partire dall’annuncio del 9 ottobre 2026 e poi sarà disattivato. In termini indicativi, la scadenza cade nell’aprile 2027; l’azienda non ha però indicato in quell’annuncio una data e un’ora precise di spegnimento.

Per i clienti a pagamento, Deno promette assistenza nella migrazione verso Cloudflare Workers. È un impegno utile, ma non equivale alla garanzia che ogni applicazione possa essere spostata senza modifiche, costi aggiuntivi o verifiche. Chi dipende da Deploy dovrà valutare compatibilità delle API, configurazioni, gestione dei dati, dipendenze esterne e differenze di fatturazione. La portabilità va provata sul software che funziona, non sul manifesto delle aziende.

Per chi si avvicina ora all’argomento, la distinzione è semplice: il runtime è il motore che esegue il codice; Deploy è uno dei luoghi in cui quel motore è stato offerto come servizio. La chiusura del secondo non cancella automaticamente tutti gli utilizzi del primo. Ma ricorda che un servizio cloud può scomparire anche quando la tecnologia sottostante resta disponibile.

Il runtime Deno resta open source, ma lo sviluppo del team ha una scadenza

La seconda decisione riguarda il progetto originario. Dahl ha annunciato dodici mesi di rilasci mensili dedicati a correzioni di bug e aggiornamenti di sicurezza. Trascorso l’anno, il team Deno terminerà lo sviluppo del runtime, che resterà open source: eventuali contributori indipendenti potranno continuare a lavorarci. Il riferimento indicativo, contando dall’ottobre 2026, è ottobre 2027.

Questa prospettiva non autorizza a dichiarare Deno «morto». Il software libero può sopravvivere a un’azienda, essere mantenuto da una comunità o trovare nuovi finanziatori. Ma non è corretto neppure equiparare l’esistenza pubblica del codice alla disponibilità di una squadra finanziata per aggiornarlo, correggere vulnerabilità e tenere il passo con gli standard. Tra diritto di modificare e capacità di mantenere passa tutta la differenza che separa una libertà teorica da un’infrastruttura affidabile.

Il caso dialoga con un altro articolo di Terza Pillola, dedicato alla fragilità economica della fondazione che sostiene PHP. Il web utilizza tecnologie a cui milioni di persone affidano lavoro e servizi, ma la loro manutenzione può dipendere da gruppi molto più piccoli di quanto il pubblico immagini. Con Deno la fragilità si vede in una forma diversa: il codice rimane aperto mentre le persone che lo sviluppano concentrano le risorse altrove.

Workerd, celld e Durable Objects: perché Cloudflare vuole il modello di Deno

La nuova destinazione dell’esperienza Deno non è un altro runtime separato. Cloudflare e Dahl intendono combinare workerd, il motore open source su cui si basano Cloudflare Workers, con le idee e il codice di celld, un progetto pensato per eseguire applicazioni distribuite anche su infrastrutture proprie. Il programma verrà guidato da Dahl e Bert Belder, con il contributo del team Workers.

Workers permette di eseguire codice in un’infrastruttura distribuita senza amministrare direttamente ogni server. I Durable Objects aggiungono uno stato persistente e meccanismi di coordinamento utili, per esempio, quando più persone interagiscono con una stessa applicazione. Il problema dichiarato da Cloudflare è che far funzionare questi componenti fuori dalla propria rete, con caratteristiche adatte alla produzione, è rimasto complesso. Secondo Kenton Varda, la versione open source di workerd supportava Durable Objects in modo adeguato soprattutto all’uso locale, senza la scalabilità richiesta dai casi reali.

Celld è interessante proprio perché prova a rendere quell’architettura più autonoma e gestibile: codice eseguibile su diverse macchine, meccanismi di comunicazione e persistenza coordinati, meno infrastruttura da assemblare manualmente. L’obiettivo annunciato è rendere il modello Workers uno strumento utilizzabile anche su server propri. Non è ancora la prova che qualsiasi applicazione Workers possa essere trasferita oggi senza modifiche. L’integrazione è un programma di sviluppo, non un risultato già consegnato.

Cloudflare promette meno lock-in: l’open source basta davvero?

Cloudflare affronta esplicitamente l’obiezione più prevedibile: un fornitore di servizi cloud avrebbe interesse a rendere difficile l’uscita dei clienti. L’azienda ribatte che workerd è stato reso open source anche per convincere clienti importanti a fidarsi della piattaforma, offrendo una via d’uscita concreta. È una posizione coerente con l’intenzione di migliorare il self-hosting attraverso il lavoro di Deno.

Ma il lock-in non dipende sempre dall’impossibilità di leggere il codice. Può nascere da servizi integrati, configurazioni proprietarie, credenziali, volumi di dati, strumenti di monitoraggio, competenze del personale e costi di migrazione. Avere il motore a disposizione rende più credibile la portabilità; ricostruire tutto ciò che gli sta intorno può restare costoso. È anche il motivo per cui l’uscita da Deno Deploy richiede assistenza e una finestra di transizione.

La questione è vicina a quella già discussa nell’analisi sulla sovranità digitale e la dipendenza dal cloud. Un paese, un’impresa o uno sviluppatore possono possedere i propri dati e continuare comunque a dipendere dal modo in cui una piattaforma li esegue, li sposta e ne coordina i servizi. L’apertura del codice è una difesa importante, non una bacchetta magica.

Perché tutto questo riguarda anche gli agenti di intelligenza artificiale

Il legame con l’AI non è un’aggiunta pubblicitaria. Dahl indica espressamente gli agenti come uno dei contesti in cui servono nuove astrazioni. Un agente che opera per minuti o ore deve poter conservare lo stato di un lavoro, ricevere eventi, dialogare con altri servizi e riprendere un’attività senza ricostruire ogni volta l’ambiente. La combinazione di esecuzione serverless, persistenza e comunicazione in tempo reale promette di semplificare questi compiti.

Il problema non è soltanto far ragionare un modello, ma dargli una struttura in cui le azioni possano avvenire. Lo avevamo già affrontato spiegando come gli agenti AI autonomi cambiano il lavoro e perché identità e permessi diventano parti decisive dell’architettura. Chi offre questo ambiente operativo può influenzare costi, scalabilità, sicurezza e libertà di cambiare fornitore.

Cloudflare acquisisce persone e competenze per portare quel modello oltre la propria rete. Se il progetto riuscirà, sviluppatori e aziende potrebbero ottenere strumenti più portabili per software tradizionale e agenti AI. Se la portabilità rimarrà limitata, la concentrazione delle competenze potrà invece rafforzare il peso di un singolo ecosistema. Al 9 ottobre sono prospettive, non risultati da dare per acquisiti.

Il futuro del web non si decide soltanto nei browser

Quando si parla di internet, si guarda spesso a ciò che appare sullo schermo: motori di ricerca, social network, chat, app. Ma sotto quelle interfacce ci sono runtime, librerie, server, database e servizi che decidono quanto costa far funzionare un prodotto e quanto è difficile cambiarne fornitore. L’operazione Cloudflare-Deno rende visibile uno di questi strati, generalmente ignorato fino al momento in cui qualcosa viene spento.

Il passaggio riunisce una promessa e una rinuncia: un’infrastruttura Workers più facile da portare sui propri server, ma la fine dello sviluppo autonomo di Deno e la chiusura programmata di Deploy. Non è una contraddizione da cancellare con un comunicato. È il prezzo concreto di una scelta industriale: investire su un’architettura comune significa smettere di investire su altre.

Ci era stato raccontato che il grande vantaggio dell’open source fosse non dover chiedere permesso per continuare. È vero. Il caso Deno ricorda però un dettaglio meno romantico: per continuare occorre anche qualcuno disposto a fare il lavoro. Il codice non cambia proprietario come un’abitazione. Il tempo degli sviluppatori, invece, sì.