Deno entra in Cloudflare: un runtime aperto non basta per uscire dal cloud

Un software è open source, quindi possiamo eseguirlo dove vogliamo. È una frase rassicurante, soprattutto quando dobbiamo scegliere una piattaforma su cui costruire applicazioni destinate a durare anni. Il problema è che tra poter compilare un runtime e riuscire a far funzionare un sistema distribuito in produzione c’è di mezzo quasi tutta l’infrastruttura. E quell’infrastruttura, di solito, non è contenuta nel repository che abbiamo appena clonato.

Il 9 ottobre 2026 Cloudflare ha annunciato l’ingresso dell’intero team Deno, guidato da Ryan Dahl e Bert Belder, per integrare il lavoro su celld con workerd. L’obiettivo dichiarato è rendere il modello di programmazione di Workers e Durable Objects utilizzabile in modo serio anche su infrastrutture gestite da altri. La notizia non è soltanto una questione societaria: riguarda la distanza tra compatibilità del codice e portabilità operativa.

Il runtime era aperto. Il sistema distribuito molto meno

workerd, il runtime di Cloudflare Workers, è già open source. Cloudflare sottolinea che non si tratta di una riscrittura semplificata: è lo stesso codice utilizzato nella propria piattaforma. Questo però non equivale a dire che un’installazione autonoma offra tutte le capacità operative della rete Cloudflare. Il confine diventa evidente quando un’applicazione usa Durable Objects, cioè oggetti indirizzabili che associano esecuzione, stato persistente e coordinamento.

Nell’annuncio tecnico firmato da Kenton Varda e Ryan Dahl, Cloudflare ammette esplicitamente il limite: l’implementazione di Durable Objects in workerd funziona in modalità a singola istanza, utile per i test locali ma non adatta a scalare su più nodi. La piattaforma di produzione di Cloudflare possiede invece un sistema di instradamento e coordinamento molto più complesso, progettato per centinaia di sedi e dipendente da servizi operati da specialisti. Distribuire il binario, quindi, non significava distribuire automaticamente quel sistema.

È qui che il discorso sul lock-in diventa interessante. Un’applicazione può usare API documentate e un runtime pubblico, ma continuare a dipendere da un control plane che non sa ricreare altrove. In quel caso il vincolo non è una funzione JavaScript proprietaria: è la semantica che tiene insieme identità degli oggetti, persistenza, routing e gestione dei guasti. Il codice parte. Il servizio, magari, no.

Che cosa porta celld, e che cosa non possiamo ancora dare per scontato

celld nasce dal lavoro del team Deno su una versione self-hostable del modello Workers e Durable Objects. Dahl descrive un’architettura costruita attorno a un singolo binario Rust, con lo storage a oggetti come dipendenza esterna essenziale: più istanze del servizio possono cooperare senza richiedere a ogni applicazione di assemblare da zero database, code, routing e coordinamento. È una scelta architetturale precisa, non semplicemente un altro modo di avviare JavaScript.

Il piano annunciato consiste nel portare codice e idee di celld dentro workerd, facendo del self-hosting una modalità supportata di primo livello. Ma la parola importante è piano. Oggi è possibile eseguire autonomamente i progetti esistenti; non è stato annunciato che l’integrazione sia già completata, né che ogni funzione della piattaforma gestita abbia già un equivalente pronto e verificato. Cloudflare promette ulteriori dettagli nei prossimi mesi. Presentare questa direzione come una migrazione senza attriti già disponibile sarebbe confondere una roadmap con un prodotto consegnato.

La portabilità non si misura chiedendo se un’applicazione si avvia fuori dal cloud. Si misura chiedendo quali garanzie restano vere quando togliamo il cloud che la teneva in piedi.

Il vero test è lo stato, non il primo deploy

Un Worker stateless che riceve una richiesta e restituisce una risposta è relativamente semplice da spostare. La complessità cresce quando entrano in gioco Durable Objects, WebSocket, stato persistente e interazioni fra più servizi. Chi decide dove vive un oggetto? Come viene ripristinato dopo un guasto? Cosa accade quando due nodi provano a raggiungerlo contemporaneamente? Come si migrano i dati senza perdere coerenza? Sono domande meno appariscenti di una demo, ma sono proprio quelle che distinguono un runtime utilizzabile da una piattaforma gestibile.

La promessa di un binario più storage a oggetti è interessante perché riduce il numero di componenti che dobbiamo coordinare. Non elimina, però, la responsabilità di dimensionare lo storage, osservare le latenze, pianificare backup, misurare costi, testare il ripristino e capire le condizioni di consistenza. Se il risultato finale richiede una squadra dedicata soltanto per tenere in piedi il sistema, abbiamo spostato il problema dal fornitore all’organizzazione: non necessariamente lo abbiamo risolto.

È un tema che ho già affrontato da un’altra prospettiva ragionando su quanto una migrazione cloud esponga assunti infrastrutturali nascosti. Qui il percorso è inverso, dal servizio gestito all’infrastruttura propria, ma il rischio è identico: scoprire durante il trasloco che il contratto tecnico vero non era l’API visibile, bensì tutto ciò che lavorava dietro.

Perché a Cloudflare dovrebbe convenire una porta d’uscita?

Cloudflare sostiene che la disponibilità del runtime open source abbia aiutato a convincere grandi clienti ad adottare Workers: nell’annuncio cita esplicitamente le richieste di aziende come Shopify. Il ragionamento commerciale non è paradossale come sembra. Se un cliente teme di non poter mai cambiare fornitore, potrebbe non entrare affatto. Rendere credibile una via di uscita può ridurre il rischio percepito dell’adozione, anche quando la maggioranza degli utenti continuerà a preferire il servizio gestito.

Questa è una lettura strategica, non una garanzia contrattuale. Il fatto che il fornitore abbia interesse a offrire portabilità non significa che ogni workload sia già portabile, né che i costi di migrazione siano trascurabili. Le condizioni vanno verificate sul prodotto effettivo e sul proprio carico. Come nel caso di Cloudflare Basin e dei formati dati aperti, il valore di un’interfaccia trasferibile si vede soltanto quando proviamo davvero a cambiare motore, non quando leggiamo che in teoria potremmo farlo.

Nel frattempo Deno non resta immutato

C’è poi l’altra metà della notizia, quella che interessa chi ha investito direttamente nel runtime Deno. Nel messaggio ufficiale di Ryan Dahl si legge che Deno continuerà a ricevere rilasci mensili di correzioni e sicurezza per un anno; al termine il team cesserà lo sviluppo del runtime, che rimarrà open source e potrà essere portato avanti dalla comunità. Deno Deploy continuerà a funzionare per sei mesi prima della chiusura, con supporto alla migrazione verso Cloudflare Workers per i clienti paganti. JSR proseguirà, trasferendo la propria infrastruttura a Cloudflare, e il supporto a rusty_v8 continuerà.

Non significa che domani ogni progetto Deno smetta di funzionare. Significa, però, che la traiettoria di manutenzione ufficiale cambia in modo sostanziale. Un’organizzazione che usa Deno in produzione dovrebbe censire versioni, dipendenze, ambienti di esecuzione, servizi Deploy e responsabilità di aggiornamento, senza aspettare l’ultimo mese. La differenza fra software ancora eseguibile e software con una manutenzione affidabile è molto concreta quando arriva una vulnerabilità o cambia una dipendenza di sistema.

Anche Simon Willison, commentando l’annuncio, evidenzia la fine programmata dello sviluppo del runtime da parte del team. È un promemoria utile: un’acquisizione può rafforzare un’idea tecnica e contemporaneamente chiudere il percorso di un prodotto. Non serve trasformare la notizia in un funerale del JavaScript, ma nemmeno raccontarla come se nessuno dovesse rivedere la propria roadmap.

Le verifiche da fare prima di chiamare una piattaforma portabile

Per un progetto che stia valutando Workers e Durable Objects, il confronto non dovrebbe limitarsi al costo per richiesta o al tempo necessario a scrivere la prima funzione. Le domande operative sono almeno cinque:

• Compatibilità: quali API e quali comportamenti di Durable Objects sono realmente supportati nella versione self-hosted scelta?
• Stato: come si esportano, ripristinano e verificano dati e identificativi degli oggetti, compresi gli scenari di guasto?
• Operatività: chi gestisce aggiornamenti, segreti, osservabilità, instradamento e capacità fra nodi?
• Costi: quanto costa il sistema completo, incluso il lavoro di esercizio, e non soltanto il binario?
• Uscita: esiste una prova ripetibile di migrazione su un ambiente alternativo, con test funzionali e misure di prestazione?

Non è una checklist inventata per rendere difficile una scelta semplice. È il minimo necessario per capire se stiamo acquistando una piattaforma, un linguaggio di programmazione o una dipendenza organizzativa. E sono tre cose diverse, anche quando vengono vendute nello stesso pannello di controllo.

L’architettura aperta si dimostra quando si può cambiare idea

L’ingresso del team Deno in Cloudflare è interessante perché riconosce pubblicamente una lacuna reale: il runtime da solo non bastava a portare fuori dalla piattaforma le capacità distribuite che rendevano Workers attraente. Se l’integrazione fra celld e workerd riuscirà, il vantaggio non sarà avere un’altra icona nella lista dei framework. Sarà poter scegliere dove eseguire un modello applicativo senza doverne ricostruire ogni volta l’infrastruttura fondamentale.

Fino ad allora la distinzione resta netta. Il codice aperto è una condizione utile, ma non una prova di indipendenza. Il lock-in si riduce quando possiamo verificare un percorso di uscita, stimarne il costo e ripeterlo senza affidare la riuscita a una promessa commerciale. Tutto il resto è documentazione incoraggiante, che in produzione vale meno di un test di ripristino riuscito.