Il team di Deno si unisce a Cloudflare dal 9 ottobre 2026. L'operazione comporta la chiusura di Deno Deploy in sei mesi e la fine dello sviluppo del runtime Deno dopo un anno di manutenzione, spostando il focus su workerd e celld.
Il 9 ottobre 2026 è stato ufficialmente annunciato che l'intero team di Deno entrerà a far parte di Cloudflare. Questa transizione non rappresenta una semplice acquisizione di talenti, ma comporta una ridefinizione drastica del ciclo di vita dei prodotti Deno. Il runtime Deno entrerà in una fase di manutenzione limitata: sarà supportato per un solo anno attraverso rilasci mensili focalizzati esclusivamente su correzioni di bug e aggiornamenti di sicurezza. Al termine di questo periodo di dodici mesi, lo sviluppo ufficiale del runtime da parte del team verrà interrotto definitivamente. [1]
Deno Deploy, il servizio di hosting gestito, continuerà invece a operare per sei mesi prima della chiusura. Chi lo usa deve quindi pianificare il trasferimento dell’applicazione mentre il servizio è ancora operativo. La fine dello sviluppo del runtime da parte del team non cancella il codice: Deno rimarrà open source e altri potranno proseguirne lo sviluppo. Un eventuale fork, però, andrà valutato sulla base di manutentori, aggiornamenti e compatibilità effettivi; non costituisce una soluzione già garantita dall’annuncio.
Deno è nato con l'obiettivo di risolvere criticità strutturali del software server, concentrandosi sulla distribuzione dei moduli, sulle garanzie di sicurezza del runtime JavaScript e sulla creazione di una toolchain completa che permettesse la distribuzione di applicazioni come eseguibili standalone. Un pilastro fondamentale di questo lavoro è stata la compatibilità con Node.js, implementata per consentire agli sviluppatori di beneficiare delle innovazioni di Deno senza dover rinunciare all'accesso all'esteso ecosistema di pacchetti JavaScript esistente. [1]
La scelta annunciata dal team è concentrare il futuro sviluppo sulla piattaforma condivisa, anziché proseguire con un runtime e un servizio di hosting separati. Per chi mantiene un progetto, la prima domanda pratica riguarda le dipendenze: quali parti sono normale JavaScript o TypeScript e quali richiedono API specifiche di Deno? È un inventario utile anche senza cambiare immediatamente ambiente. Permette di separare il lavoro urgente sul servizio di hosting dalle decisioni sul runtime, che ha un periodo di manutenzione più lungo.
Sintesi dei fatti documentati nell’articolo. I riferimenti sono riportati sotto lo schema.
Con la chiusura di Deno Deploy prevista entro sei mesi, Cloudflare ha annunciato che fornirà supporto alla migrazione verso Cloudflare Workers specificamente per i clienti a pagamento. Questo processo richiede un'analisi accurata delle dipendenze infrastrutturali, poiché Deno Deploy offriva un'esperienza di deployment semplificata che ora deve essere mappata sui primitivi di Workers, che operano su un modello di esecuzione differente rispetto ai processi tradizionali. [1]
Per illustrare concretamente la migrazione, consideriamo un'applicazione che gestisce un'API di notifiche, un sistema di scheduling per la pulizia di un database e uno storage per i file degli utenti. In Deno Deploy, queste funzioni erano integrate in un unico ecosistema. Migrando a Cloudflare Workers, l'API diventa un Worker standard; lo storage dei file viene spostato su R2, il servizio di storage di oggetti non strutturati. Per i dati strutturati, la scelta ricade tra D1, il database SQL serverless, o Durable Objects. Se l'applicazione richiede che più client coordinino lo stato in tempo reale (ad esempio un sistema di chat o un editor collaborativo), la scelta tecnica corretta è l'adozione di Durable Objects, che agiscono come singleton distribuiti con storage SQLite integrato, evitando la latenza di un database centralizzato. [3]
Un possibile criterio di accettazione della migrazione è preparare una piccola sequenza di richieste rappresentative, conservando per ciascuna l’esito atteso e i dati necessari. Nell’esempio delle notifiche, la sequenza può comprendere un invio normale, una richiesta ripetuta e un errore temporaneo dello storage. Ripeterla nel nuovo ambiente aiuta a individuare differenze prima del passaggio del traffico. È un piano di verifica illustrativo: i casi reali dipendono dalle funzioni e dai dati del servizio.
Cloudflare Workers differisce dai runtime tradizionali per l'uso di un modello di esecuzione che permette un avvio rapido e un consumo di risorse ridotto. Un elemento chiave di questa architettura sono i Durable Objects: Worker speciali che combinano calcolo e storage persistente. Ogni Durable Object possiede un nome globalmente unico, permettendo di indirizzare richieste a un'istanza specifica da qualsiasi parte del mondo. Questo modello implementa un singleton distribuito con un database SQLite sincrono, supportando nativamente WebSockets e garantendo coerenza forte dei dati. [2][3]
Questo modello consente di avvicinare la logica dell’applicazione al suo stato persistente. L’esempio della chat chiarisce la scelta: un oggetto per stanza può diventare il punto a cui indirizzare le richieste di quella conversazione. È una proposta di organizzazione, non la promessa che basti cambiare un’API per rendere scalabile qualsiasi applicazione. Chi migra deve ancora verificare comportamento concorrente, accesso ai dati e risposta agli errori. Il vantaggio da valutare è il modello di coordinamento offerto dalla piattaforma, rispetto alle esigenze del progetto concreto.
Il progetto celld, ideato da Ryan Dahl, è stato sviluppato per semplificare l'operatività di applicazioni distribuite attraverso un singolo binario scritto in Rust, che ha come unica dipendenza esterna un bucket di object storage. L'obiettivo strategico di Cloudflare è ora quello di fondere celld con workerd, il runtime open source che alimenta Cloudflare Workers. Questa integrazione mira a rendere il self-hosting del modello di programmazione di Workers e Durable Objects un'opzione di prima classe per gli sviluppatori che desiderano eseguire le proprie applicazioni su infrastruttura privata. [1][2]
Cloudflare descrive un limite preciso di workerd: l’implementazione dei Durable Objects consentiva di eseguirli su un singolo server, senza offrire la distribuzione necessaria al modello su più macchine. Integrare celld serve a colmare questa distanza. L’annuncio indica quindi una direzione di sviluppo; non dimostra che l’intero sistema distribuito sia già disponibile per qualunque installazione privata. Prima di pianificare un’adozione, occorre controllare quali componenti siano effettivamente rilasciati e quali restino obiettivi dell’integrazione.
A differenza del runtime e di Deploy, JSR (JavaScript Registry) continuerà a operare normalmente, sebbene la sua infrastruttura venga migrata verso Cloudflare. Parallelamente, Cloudflare e il team di Deno continueranno a supportare rusty_v8, con l'obiettivo di integrarlo all'interno di workerd. [1]
Per organizzare la migrazione conviene annotare, per ogni componente, API usate, dati da trasferire e verifica necessaria dopo il cambio di ambiente. Un esempio illustrativo è l’API di notifiche: oltre alla risposta HTTP, vanno controllati invio duplicato, tentativi dopo un errore e accesso allo storage. Sono verifiche dell’applicazione, non proprietà che l’annuncio garantisce automaticamente. Per JSR la comunicazione conferma la prosecuzione del servizio; per Deploy fissa invece sei mesi. Separare queste due situazioni evita di trattare ogni dipendenza Deno come se avesse la stessa scadenza.
Il design introdotto con Firefox 157 cambia barre, temi e sidebar. Ecco le differenze pratiche, le correzioni video e i limiti da conoscere prima di cambiare impostazioni.
Analisi tecnica di Ubuntu 26.10 "Stonking Stingray", focalizzata sulla riduzione della superficie di attacco, l'adozione totale di Rust per le core utilities e le nuove misure di crittografia TPM.
Rilasciata il 12 ottobre 2026, la versione v0.1.0-preview.1 di Tiny11 Builder evolve in un'app WinUI in C# per creare ISO di Windows 11 ridotte, introducendo modalità di rimozione differenziate e ottimizzazioni Turbo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.