In sintesi
Deno come prodotto indipendente ha ora una data di fine. Il 9 ottobre 2026 Ryan Dahl e Kenton Varda di Cloudflare hanno annunciato che l'intero team di Deno entra in Cloudflare. Deno Deploy, la piattaforma gestita, resterà attiva per sei mesi e poi chiuderà. Il runtime Deno riceverà per un anno rilasci mensili con correzioni di bug e aggiornamenti di sicurezza, dopodiché lo sviluppo ufficiale terminerà. Il codice resta open source, quindi la community potrà portarlo avanti.
Il nuovo compito del team è far funzionare il modello di programmazione di Cloudflare Workers ovunque, anche sui vostri server. Per la maggior parte dei clienti di Deno Deploy la strada pratica è il passaggio a Workers, e Cloudflare dichiara che aiuterà i clienti paganti nella migrazione.
Cosa hanno annunciato Cloudflare e Deno?
In un post congiunto Dahl e Varda spiegano che il team di Deno lavorerà per portare il modello Workers in più contesti. Il piano concreto è far confluire codice e idee di Celld in workerd, il runtime open source che già alimenta Cloudflare Workers in produzione. Celld è un singolo binario Rust la cui unica dipendenza esterna è un object storage, quindi può essere ospitato in proprio senza la rete di Cloudflare.
L'annuncio di Deno chiarisce cosa succede ai suoi prodotti. Deno Deploy ha sei mesi prima della chiusura. Il runtime entra in manutenzione: rilasci mensili con correzioni e patch di sicurezza per un anno dall'annuncio, poi nessuno sviluppo ufficiale. JSR resta online e passa sull'infrastruttura di Cloudflare. TechCrunch e The New Stack hanno riportato l'operazione il 9 e 10 ottobre, sottolineando che i termini non sono stati resi noti.
Perché Cloudflare vuole Deno?
La partita riguarda il modello di programmazione, non il marchio del runtime. Deno Deploy e Workers si contendevano gli stessi clienti del serverless all'edge, e Celld aveva dimostrato che Deno poteva offrire il modello Workers senza Cloudflare. Portando questo lavoro in casa, Cloudflare ottiene un'offerta ufficiale self-hosted per Workers e Durable Objects. È un punto importante per chi apprezza il modello ma non può eseguire ogni carico sulla rete di un terzo, per esempio per vincoli di residenza dei dati o requisiti on-premise. Varda ha definito l'open source e una «via d'uscita» una buona scelta di business, e Dahl ha detto che l'obiettivo è rendere il modello Workers un modo standard di costruire server.
Cosa cambia per i team software negli Stati Uniti e nell'UE
Primo: è l'uscita da un fornitore con una scadenza. Tutto ciò che gira su Deno Deploy deve trovare una nuova casa entro sei mesi: codice, variabili d'ambiente, job pianificati, dati KV, domini personalizzati e TLS. Trattatelo come qualsiasi dismissione di piattaforma: censire cosa gira lì, scegliere la destinazione e pianificare un cutover con piano di rollback, invece di aspettare le ultime settimane.
Secondo: un runtime in manutenzione è un tema di sicurezza. Dopo la finestra di un anno, un runtime Deno senza patch ufficiali sarà più difficile da giustificare negli audit SOC 2, ISO 27001 o NIS2, dove il software non supportato è un rilievo tipico. Chi ospita Deno in proprio dovrebbe annotare subito la data di fine supporto nel registro dei rischi e decidere se affidarsi a un fork della community, passare a Workers tramite workerd o portare il codice su Node.js, con cui Deno puntava già alla compatibilità.
Terzo: il modello Workers self-hosted potrebbe cambiare le scelte di architettura edge. Se workerd erediterà la semplicità di self-hosting di Celld, lo stesso codice potrebbe girare sulla rete di Cloudflare negli Stati Uniti e sui vostri server in una region europea. È utile per i carichi regolamentati di FinTech e HealthTech, ma per ora è un piano, non un prodotto rilasciato. Non progettate su questa base finché non ci sarà una release con operatività documentata.
Cosa significa per il mercato italiano?
In Italia Deno Deploy era usato soprattutto da startup, web agency e software house per funzioni edge, webhook e piccole API, spesso al di fuori del contratto cloud principale e quindi poco visibile a IT e procurement. Per le PMI che si appoggiano a un fornitore esterno, il primo passo è chiedere esplicitamente quali servizi girano su Deno Deploy. Per la Pubblica Amministrazione il tema è diverso: i servizi cloud usati dagli enti devono essere qualificati dall'Agenzia per la Cybersicurezza Nazionale (ACN), quindi una migrazione verso un nuovo fornitore va verificata anche sotto questo profilo, non solo tecnicamente.
Sul piano normativo il caso è un esempio concreto di exit strategy. Banche, assicurazioni e intermediari soggetti al regolamento DORA devono avere strategie di uscita documentate e testate per i fornitori ICT che supportano funzioni essenziali o importanti, e una chiusura annunciata con sei mesi di preavviso è esattamente lo scenario da coprire. Il Data Act europeo, applicabile da settembre 2025, disciplina inoltre il passaggio tra fornitori di servizi cloud. In pratica: registrate la migrazione nel piano di uscita e aggiornate le nomine a responsabile del trattamento (art. 28 GDPR) con il nuovo fornitore.
Cosa devono fare ora gli utenti di Deno?
- Censire i progetti su Deno Deploy. Elencare ogni progetto con domini, variabili d'ambiente, job pianificati ed eventuali dati in Deno KV, oltre al relativo responsabile.
- Scegliere una destinazione per ogni carico. Il codice di gestione delle richieste basato su API web standard di solito si porta su Workers con modifiche contenute. Il codice che dipende da API specifiche di Deno o da processi di lunga durata può adattarsi meglio a Node.js in container.
- Pianificare prima la migrazione dei dati. Spostare i dati KV e le funzionalità con stato richiede più tempo che spostare il codice. Esportate presto e testate i ripristini.
- Bloccare la versione e monitorare il runtime. Per Deno in self-hosting, fissate una versione, seguite i rilasci mensili di sicurezza e inserite la data di fine supporto nel registro dei rischi.
- Verificare le dipendenze JSR. JSR resta online, ma controllate che la vostra CI risolva ancora i pacchetti dopo il cambio di infrastruttura e mantenete un lockfile.
Domande frequenti
Cloudflare sta acquisendo Deno?
Sì. Il 9 ottobre 2026 Deno e Cloudflare hanno annunciato che l'intero team di Deno, compresi i cofondatori Ryan Dahl e Bert Belder, entra in Cloudflare. I termini economici non sono stati resi noti.
Quando chiuderà Deno Deploy?
Secondo Deno, Deno Deploy resterà operativo per sei mesi dall'annuncio del 9 ottobre 2026 e poi chiuderà, quindi intorno ad aprile 2027. I clienti paganti ricevono assistenza per migrare a Cloudflare Workers.
Il runtime Deno viene dismesso?
Non subito. Deno pubblicherà per un anno rilasci mensili con correzioni di bug e aggiornamenti di sicurezza. Dopo, lo sviluppo ufficiale terminerà, ma il runtime resta open source e la community potrà proseguirlo.
Cosa succede a JSR?
JSR, il registro di pacchetti JavaScript creato dal team di Deno, resterà operativo. La sua infrastruttura passa a Cloudflare.
Conviene migrare a Cloudflare Workers o a Node.js?
Dipende dal carico. Il codice di gestione delle richieste basato su API web standard di solito si porta su Workers con modifiche contenute. Il codice che si appoggia ad API specifiche di Deno, processi di lunga durata o molto stato locale è spesso più facile da spostare su Node.js in container. Decidete servizio per servizio, non per l'intera azienda.
Fonti
Deno — Deno is joining Cloudflare
Cloudflare — Deno joins Cloudflare (Ryan Dahl and Kenton Varda)
TechCrunch — Cloudflare acquires Deno to improve its Workers programming model
The New Stack — Cloudflare acquires Node.js creator’s startup that copied its serverless playbook