Deno hosting: dove migrare da Deploy nel 2026

Chi cerca alternative per il Deno hosting dovrebbe valutare prima Cloudflare Workers: Deno lo indica come destinazione per la migrazione e dichiara che Deploy resterà operativo per altri 6 mesi. Netlify è adatto a un sito con logica edge basata su Deno, Supabase Edge Functions a un’API che si appoggia a un database, Vercel Functions a un’app costruita attorno a un framework e Val Town a piccole attività pianificate. Se l’app usa Deno KV, conviene scegliere il nuovo sistema di archiviazione prima della piattaforma su cui eseguire le funzioni.

Prezzi e documentazione verificati il 12 ottobre 2026. Il confronto riguarda listini pubblici, modalità di esecuzione e interventi necessari alla migrazione; non sono stati effettuati test di deployment con accesso alle piattaforme. La finestra di chiusura è quella indicata nell’annuncio di Deno del 9 ottobre.

Deno hosting: le alternative a Deploy a confronto

La destinazione migliore è quella che conserva il comportamento dell’applicazione richiedendo meno modifiche da mantenere nel tempo. Migrare un endpoint TypeScript che interroga un database esterno è ben diverso dal trasferire un’app le cui transazioni, pianificazioni e code dipendono interamente da Deno Deploy.

Le fonti dei piani sono Cloudflare, Netlify, Supabase, Vercel, Val Town, le relative FAQ sulla fatturazione e il listino VPS di DigitalOcean. Sono prezzi di partenza: il costo mensile dell’intera applicazione può essere diverso.

Che cosa ha annunciato Deno e quali sono i tempi?

Deno Deploy chiuderà, mentre il runtime Deno ha una finestra di manutenzione distinta. Nell’annuncio del 9 ottobre 2026, Ryan Dahl ha scritto:

Deno Deploy continuerà a funzionare per sei mesi prima di chiudere.

Lo stesso annuncio promette assistenza alla migrazione per i clienti paganti che passano a Cloudflare Workers. Prevede inoltre un altro anno di rilasci mensili del runtime Deno con correzioni di bug e aggiornamenti di sicurezza, dopodiché Deno ne terminerà lo sviluppo. Il runtime rimane open source. JSR, il registro dei pacchetti JavaScript e TypeScript, continuerà a operare trasferendo la propria infrastruttura su Cloudflare. Leggi l’annuncio di Deno.

Deno indica finestre temporali, senza fissare un giorno preciso di chiusura. Non bisogna ricavarne una scadenza inventata, né confondere il periodo di manutenzione più lungo del runtime con tempo aggiuntivo per Deploy. I clienti paganti dovrebbero sfruttare l’assistenza disponibile e pianificare insieme il trasferimento dell’applicazione e dei dati.

1. Cloudflare Workers: la prima destinazione da valutare

Cloudflare Workers è una piattaforma gestita per eseguire handler HTTP e attività in background. È il primo candidato da considerare perché Deno vi indirizza esplicitamente i propri clienti. Per chi gestisce un prodotto con un’API TypeScript, un database esterno e un’attività di pulizia pianificata, il lavoro principale riguarda l’adattamento delle parti legate al runtime e della configurazione di deployment. Un’app costruita attorno a Deno KV richiede invece una riprogettazione separata dello storage. Scegli Workers come piattaforma di destinazione, prevedendo un impegno specifico per le parti legate a Deno che dovranno essere modificate.

Ideale per: API, webhook, cron job, code e siti che beneficiano di un’infrastruttura gestita.
Punto di forza: è la destinazione indicata da Deno e dispone di servizi di storage e pianificazione.
Prezzi: Workers Free; Workers Paid prevede un minimo di $5 USD/mese per account; l’utilizzo di Enterprise segue le condizioni del contratto.
Prova gratuita: il piano Workers Free, senza scadenza, permette di valutare il servizio gratuitamente.
Impegno di migrazione: da basso a medio per gli handler senza stato; alto quando occorre riprogettare transazioni KV e attività in coda.

Che cosa cambia nel codice TypeScript?

Workers esegue il runtime workerd, non il runtime Deno, e non espone il namespace globale Deno. Le interfacce web standard, come Request, Response e fetch, offrono una buona base per il codice portabile. Deno.serve, Deno.env, Deno.openKv e Deno.cron segnalano invece punti da sostituire. Anche la compatibilità con Node.js copre solo una parte delle API: riuscire a importare un pacchetto in sviluppo non dimostra che le sue dipendenze funzioneranno in esecuzione. API del runtime Workers.

Wrangler è lo strumento a riga di comando di Cloudflare per il deployment. Il tutorial di Deno su Wrangler mostra come mantenere Deno nella toolchain di sviluppo: aggiungere npm:wrangler, generare i tipi di Workers, esportare un modulo con un handler fetch e creare il bundle con esbuild e il plugin Deno quando serve la risoluzione dei moduli di Deno. Usare Deno per preparare il codice da caricare non trasforma il Worker pubblicato in un processo Deno.

Sposta segreti e accesso alle risorse nei binding, i riferimenti configurati che permettono a un Worker di raggiungere database, code o valori d’ambiente. Controlla anche le dipendenze, oltre ai file dell’applicazione: una funzione di utilità può nascondere una chiamata al filesystem anche se l’handler della rotta usa soltanto API web. Binding di Cloudflare.

Sostituire i servizi in base al loro comportamento

La distinzione decisiva è tra Workers KV e Deno KV. Workers KV privilegia letture frequenti e scritture relativamente rare; i dati letti dalla cache possono non essere aggiornati. La somiglianza del nome non basta per migrare prenotazioni di scorte, saldi di conto o controlli atomici di unicità. Come funziona Workers KV.

D1 è la strada SQL: prefissi delle chiavi e indici secondari vanno trasformati in uno schema progettato con criterio. La sua API batch esegue le istruzioni in modo transazionale, ma non converte automaticamente i controlli ottimistici di Deno. Durable Objects combina stato e un’istanza di calcolo che ne coordina l’accesso: merita attenzione quando un’entità, come una stanza o un account, richiede operazioni coordinate in sequenza. Transazioni di D1, Durable Objects.

Per le attività pianificate, Cron Triggers usa un handler scheduled e orari UTC. Per quelle differite, Queues fornisce il sistema di messaggistica. Una pianificazione stabilisce quando avviare il lavoro; una coda conserva quello in attesa di elaborazione. Sostituire l’una non sostituisce l’altra. I siti statici possono usare Workers Static Assets, mantenendo i file generati separati dalla logica delle richieste dinamiche.

Prezzi e limiti da considerare

Workers Free include 100,000 richieste al giorno e 10 ms di CPU per invocazione. Paid include 10 milioni di richieste e 30 milioni di millisecondi di CPU al mese; oltre queste soglie, applica $0.30 per ogni milione di richieste aggiuntive e $0.02 per ogni milione di millisecondi di CPU aggiuntivi. Vanno conteggiati anche database, code e utilizzo degli altri prodotti. Prezzi attuali di Workers.

La sola dimensione del bundle non è più un motivo per passare a Paid: sia Free sia Paid consentono 64 MiB non compressi, mentre la memoria resta a 128 MB. Consulta i limiti attuali e il nostro approfondimento sul passaggio di piano per la dimensione del bundle. La recensione di Cloudflare spiega invece come si integrano i diversi prodotti dell’account.

1. 1

   Individuare tutte le dipendenze dal runtime

   Cerca chiamate al namespace Deno, import da URL, accessi al filesystem, segreti, operazioni KV, pianificazioni e consumer delle code. Separa la logica applicativa portabile dagli adattatori che la collegano alla piattaforma.

2. 2

   Preparare un punto di ingresso adatto a Workers

   Segui il tutorial di Deno su Wrangler: configura l’handler del modulo e i tipi generati per Workers, poi imposta una build personalizzata compatibile con Deno se gli import lo richiedono. Mantieni il comportamento delle risposte mentre cambi il modo in cui viene invocato l’handler.

3. 3

   Configurare stato e trigger in modo esplicito

   Scegli il database prima di importare i record. Aggiungi i binding, trasferisci le pianificazioni a Cron Triggers e riscrivi produttori e consumer delle code. Documenta che cosa accade se un’attività viene consegnata di nuovo.

4. 4

   Provare la migrazione prima di spostare il traffico

   Usa dati di prova locali e un ambiente di destinazione separato per confrontare codici di stato, header, autenticazione e modifiche allo stato. Pubblicare il codice è soltanto una tappa: dati e attività in background devono essere pronti per lo stesso passaggio.

2. Netlify: per i siti con logica edge basata su Deno

Netlify è una piattaforma di deployment per siti web con Edge Functions basate su Deno. Si adatta ai siti il cui lavoro dinamico riguarda le richieste in ingresso: localizzazione, controlli di autenticazione, reindirizzamenti o personalizzazione leggera. Mantenere questa logica accanto alle anteprime di deployment del sito può essere più utile che adottare un nuovo modello infrastrutturale. Un handler edge senza stato è un candidato ragionevole alla migrazione; un backend che dipende molto dalle code richiede una maggiore separazione dei componenti. Scegli Netlify quando il prodotto è il sito web e la logica edge lo affianca. Panoramica di Edge Functions.

Ideale per: siti statici e applicazioni web con logica leggera basata su Deno per gestire le richieste.
Punto di forza: Edge Functions pubblicate insieme al sito, con anteprime e rollback.
Prezzi: Free $0 per sempre; Personal $9/mese; Pro $20/mese con membri illimitati; Enterprise su preventivo.
Prova gratuita: Free include un limite mensile di 300 crediti.
Impegno di migrazione: da basso a medio per un sito e una logica edge senza stato; maggiore quando occorre separare storage, pianificazioni e consumer delle code.

Il runtime resta familiare, ma cambiano le regole dell’applicazione

Una Edge Function usa l’handler e il contesto di Netlify. Vanno rivisti anche gli import: la documentazione prevede un file import map separato, anziché la mappa contenuta in deno.json, e descrive il supporto ai pacchetti npm come beta. Per un progetto che oggi risolve le dipendenze tramite la configurazione di Deno, questo è un intervento concreto da pianificare. API di Edge Functions.

Il limite di esecuzione è 50 ms di CPU per richiesta, con un timeout di 40 secondi per gli header della risposta. Attendere un servizio remoto e trasformare un documento di grandi dimensioni consumano risorse diverse. Una verifica di autenticazione può rientrare in una logica edge leggera; un’elaborazione intensiva sulla CPU richiede un percorso di esecuzione diverso. Limiti di Edge Functions.

Come sostituire Deno KV, cron e code

Usa Netlify Blobs per i contenuti adatti all’accesso tramite chiave e Netlify Database, il servizio Postgres della piattaforma, quando servono dati relazionali e aggiornamenti transazionali. Blobs offre letture a coerenza forte opzionali, ma queste da sole non riproducono l’API atomica multichiave di Deno KV. Il nuovo sistema di storage deve conservare le regole applicative, per esempio impedire nomi utente duplicati.

Le Scheduled Functions sono una funzionalità distinta di Netlify Functions. Una Edge Function che contiene Deno.cron non ottiene automaticamente una pianificazione gestita. Separa l’attività, configurane la pianificazione e verifica il runtime con cui verrà eseguita. Se prima consumava una coda Deno KV, individua esplicitamente dove conservare i messaggi in modo durevole e quale consumer li elaborerà: pianificare una funzione non trasferisce i messaggi in coda.

Per chi gestisce un sito di contenuti con una sincronizzazione ogni ora, questa separazione è affrontabile: distribuzione del sito e personalizzazione restano sulla piattaforma web, mentre la sincronizzazione ha una propria funzione pianificata e uno stato persistente. La soluzione è meno interessante quando gran parte dell’app consiste in worker in background che dipendono gli uni dagli altri.

Calcolare crediti e costi del team

Personal include 1,000 crediti/mese. Le fasce di credito di Pro sono 3,000 a $20, 5,000 a $33, 10,000 a $63, 15,000 a $95 e 20,000 a $126, al mese. Le fasce superiori, a partire da 5,000 crediti, consentono di riportare i crediti mensili inutilizzati al ciclo di fatturazione successivo; la fascia base non lo permette. Fasce di credito attuali di Netlify.

La ricarica automatica è disattivata per impostazione predefinita. Se attivata, Personal può aggiungere 500 crediti a $5 e Pro 1,500 a $10. Esaurire la quota dell’account senza acquistare altri crediti può sospenderne i progetti: un lancio pubblico richiede quindi anche una decisione sulla spesa. Questi piani a crediti non vanno confusi con i vecchi prezzi di Netlify basati sul numero di utenti.

3. Supabase Edge Functions: per le API che dipendono dal database

Le Supabase Edge Functions sono funzioni TypeScript eseguite su un runtime compatibile con Deno. Sono particolarmente adatte quando la migrazione coincide con una scelta precisa: portare i dati su Postgres, un database relazionale. Un’app in abbonamento che riceve webhook di pagamento e aggiorna i record dei clienti trova qui una destinazione naturale. Il runtime familiare riduce una parte delle modifiche, mentre il database diventa il principale lavoro di progettazione. Scegli Supabase quando sono i dati persistenti dell’applicazione a determinare l’architettura. Documentazione delle funzioni.

Ideale per: webhook e API da collocare accanto a Postgres, autenticazione e archiviazione dei file.
Punto di forza: funzioni compatibili con Deno integrate in una piattaforma database.
Prezzi: Free $0/mese; Pro da $25/mese; Team da $599/mese; Enterprise su preventivo.
Prova gratuita: Free include 500,000 invocazioni di Edge Functions e un database da 500 MB per progetto.
Impegno di migrazione: medio per gli handler compatibili; alto quando Deno KV deve diventare uno schema relazionale con una nuova logica transazionale.

Migrare il modello dei dati insieme all’endpoint

Sostituisci le chiamate a Deno KV con accessi a Postgres. Un prefisso che identifica, per esempio, gli elementi salvati da un utente diventa una relazione interrogabile; un controllo di unicità diventa un vincolo del database o una transazione. Conservare un insieme di chiavi opache solo per semplificare apparentemente l’importazione ha poco senso se ogni query importante dovrà subito decodificarle.

Un handler di pagamento, per esempio, può dover registrare un evento e aggiornare contemporaneamente un diritto di accesso. Il criterio di accettazione è che un nuovo tentativo non possa concedere quel diritto due volte. Una risposta HTTP corretta dalla nuova funzione non dimostra che questa regola sia sopravvissuta alla riscrittura dello storage.

Supabase offre anche Cron, che può eseguire operazioni sul database o invocare una Edge Function, e Queues, un sistema di messaggistica persistente basato su Postgres. Sostituisci esplicitamente con questi servizi la registrazione di Deno.cron e il codice che inserisce e consuma messaggi nella coda Deno KV. Stabilisci come confermare l’elaborazione dei messaggi e quando un’attività fallita potrà essere ritentata.

Limiti di esecuzione e costo iniziale completo

Le Edge Functions consentono 256 MB di memoria e 2 secondi di CPU per richiesta. Il limite di durata complessiva del worker è 150 secondi su Free e 400 secondi sui piani a pagamento, ma una durata maggiore non aumenta il budget di CPU. Sono limiti distinti, non modi equivalenti di descrivere un worker che può restare attivo a lungo. Limiti delle funzioni.

Pro e Team includono 2 milioni di invocazioni di funzioni, poi addebitano $2 per ogni milione aggiuntivo. Free consente 2 progetti attivi e sospende quelli inattivi dopo 1 settimana. I piani a pagamento includono un credito di calcolo di $10/mese che copre un’istanza Micro. Prezzi di Supabase.

Supabase è meno indicato per il frontend statico del sito. La documentazione sui limiti delle funzioni specifica che per servire HTML occorre un dominio personalizzato; altrimenti una risposta text/html viene riscritta come text/plain. La scelta dell’hosting per il frontend va tenuta distinta da quella della piattaforma per le API.

4. Vercel Functions: quando la scelta dipende dal framework web

Vercel Functions offre funzioni lato server gestite e associate al deployment web. È adatto alle app per cui il framework del frontend e il processo di rilascio sono il motivo principale del cambiamento. Se chi sviluppa il prodotto sta già riorganizzando l’applicazione attorno a un framework supportato da Vercel, può avere senso inserirvi anche le rotte API. È invece un percorso meno diretto per un servizio Deno che, per il resto, si vuole lasciare invariato. Scegli Vercel per il flusso di lavoro dell’applicazione, pianificando esplicitamente l’adattamento del runtime e dello storage.

Ideale per: applicazioni web costruite attorno a un framework, con rotte API accanto al frontend.
Punto di forza: un processo di deployment unificato per l’applicazione e le funzioni lato server.
Prezzi: Hobby $0/mese; Pro $20/mese; Enterprise su preventivo.
Prova gratuita: Pro propone una prova; Hobby è riservato all’uso personale non commerciale.
Impegno di migrazione: medio per adattare runtime e rotte; alto quando vanno sostituiti anche storage e attività in background.

Scegliere tra porting e runtime della community

Vercel elenca Node.js tra i runtime supportati e Deno come runtime della community, vercel-deno. Le due opzioni comportano scelte di manutenzione diverse. Quando la migrazione ha una scadenza, valuta compatibilità e responsabilità di manutenzione dell’integrazione della community prima di farne una dipendenza essenziale per la produzione. In alternativa, adatta handler e dipendenze al runtime supportato usato dal framework. Documentazione dei runtime di Vercel.

Per Deno KV, scegli un database e sostituisci l’API. La guida allo storage di Vercel distingue Blob per i file, Global Config per la configurazione e i database del Marketplace per i dati applicativi. Un archivio di configurazione non dovrebbe diventare la destinazione predefinita dei record transazionali dei clienti solo perché offre una comoda interfaccia chiave-valore.

Vercel Cron sostituisce la pianificazione, non la registrazione nel codice tramite Deno.cron. Hobby permette di eseguire un’attività una volta al giorno, con precisione oraria; Pro supporta un intervallo minimo di una volta al minuto. Una sincronizzazione frequente esclude Hobby già per questo requisito. Utilizzo e prezzi di Cron.

Vercel Queues è ora disponibile in beta su tutti i piani, con topic persistenti, tentativi automatici e consegna almeno una volta. È quindi un candidato per le attività della coda Deno KV, ma produttori, consumer e modalità di conferma dell’elaborazione vanno comunque riscritti. Se la coda è l’unico percorso per evadere un ordine cliente, lo stato beta deve pesare nella decisione.

Il prezzo cambia quando più persone devono pubblicare

Il canone della piattaforma Pro include 1 posto abilitato al deployment e $20 di credito mensile per l’utilizzo. Ogni posto a pagamento aggiuntivo costa $20/mese; i posti per la sola visualizzazione sono gratuiti. Consumi oltre il credito e componenti aggiuntivi a pagamento si conteggiano a parte. Dettagli della fatturazione Pro.

Per un’azienda che lascia Deno Deploy, il prezzo gratuito di Hobby non rappresenta il budget di produzione. Parti dal piano che consente l’uso commerciale, poi aggiungi i requisiti di database e code. In questo modo, una migrazione apparentemente economica non si trasforma in una serie imprevista di fatture separate.

5. Val Town: per piccole API e attività pianificate

Val Town è un ambiente ospitato per piccoli programmi con trigger HTTP, email e cron. È particolarmente adatto a un servizio compatto che svolge un compito preciso: un webhook che aggiorna un sistema esterno, un’API usata da uno strumento interno o un riepilogo inviato a intervalli regolari. Il runtime Deno lo rende pertinente a questa migrazione, ma le interfacce di storage e dei trigger restano diverse. Scegli Val Town quando il progetto è un’automazione circoscritta, anziché una piattaforma da gestire. Documentazione di Val Town.

Ideale per: piccole API, handler di webhook, integrazioni pianificate e strumenti interni.
Punto di forza: codice ospitato con trigger integrati e storage SQLite.
Prezzi: Free $0; Pro $21/mese con fatturazione annuale; Business da $167/mese con fatturazione annuale; Enterprise su preventivo. Le FAQ del fornitore indicano gli abbonamenti mensili a $25 per Pro e $200 per Business.
Prova gratuita: Free è un piano senza scadenza, privo di domini personalizzati e val privati.
Impegno di migrazione: basso per una piccola utility senza stato, medio per una piccola attività con dati persistenti, alto per un’applicazione più ampia con stato.

Il periodo di fatturazione conta: la pagina dei prezzi, con l’opzione annuale selezionata, non va presentata come un abbonamento disdicibile ogni mese alla stessa tariffa. Le FAQ di Val Town forniscono i prezzi con fatturazione mensile e confermano l’uso del runtime Deno.

Una migrazione contenuta richiede un progetto contenuto

Trasferisci l’handler in un val, il contenitore applicativo con versionamento di Val Town, e associalo a un trigger HTTP o cron. Per un’attività che si limita a chiamare un’API esterna e inviare un riepilogo, lo stato persistente potrebbe essere soltanto l’ultimo elemento elaborato. È molto più semplice da gestire rispetto a un’app rivolta ai clienti con più entità transazionali e consumer di code.

Quando è adatto, sostituisci Deno KV con il database SQLite dedicato a ciascun val, oppure mantieni un database esterno. Riscrivi ricerche per chiave e controlli atomici come operazioni sul database. Non lasciare Deno.openKv collegato all’archivio ospitato in dismissione considerando conclusa la migrazione.

Le attività in attesa in una coda devono comparire esplicitamente nel progetto. Un cron che controlla periodicamente una tabella di attività è una possibile soluzione applicativa, ma richiede di implementare l’assegnazione delle attività ai worker, i nuovi tentativi e la gestione dei duplicati. Non conserva automaticamente il comportamento della coda Deno KV.

Frequenza, riservatezza e durata determinano il piano

Free prevede un intervallo minimo dei cron di 15 minuti e una durata massima di 1 minuto per esecuzione. Pro riduce l’intervallo a 1 minuto e porta il limite di esecuzione a 10 minuti; la scheda del piano indica anche 10 domini personalizzati e 2,000 val privati. Prezzi e limiti attuali.

Un riepilogo giornaliero pubblico potrebbe rientrare in Free. Un’integrazione privata o un’attività che deve interrogare un servizio più spesso richiede un altro piano, anche con un traffico minimo. Riservatezza del codice e accesso all’endpoint sono inoltre requisiti distinti: avere un sorgente privato non stabilisce, da solo, chi possa chiamare l’endpoint HTTP.

L’impegno di migrazione è basso per una utility senza stato con un trigger semplice, medio quando va trasferito lo stato persistente dell’attività e alto se si cerca di riprodurre l’architettura di runtime e dati di un’applicazione più grande. Sono valutazioni dell’ampiezza del lavoro, non stime delle ore necessarie.

6. Deno in self-hosting: per conservare il comportamento del runtime

Eseguire Deno su un server privato virtuale, o VPS, permette di conservare il runtime assumendosi la responsabilità dell’hosting. Un container racchiude runtime e applicazione, così da poterli eseguire su un host a scelta. È una possibilità da considerare quando accessi al filesystem, API specifiche di Deno o comportamento dei processi di lunga durata costituiscono la parte principale del porting. Scegli il self-hosting quando mantenere il runtime evita più complessità di quanta ne aggiunga la gestione del server. Deno pubblica una guida ufficiale a Docker.

Ideale per: applicazioni che dipendono molto da Deno, gestite da chi sa amministrare un server o un deployment di container.
Punto di forza: controllo del runtime, del filesystem e del ciclo di vita dei processi.
Prezzi: il runtime open source non ha un piano di hosting gestito. Come esempio di fornitore, DigitalOcean propone un Basic Regular Droplet a $4.00/mese, con 512 MiB di RAM; l’opzione da 1 GiB costa $6.00/mese.
Prova gratuita: DigitalOcean cita crediti promozionali, ma la pagina dei prezzi non offre un piano Droplet gratuito permanente.
Impegno di migrazione: meno riscrittura legata al runtime, più responsabilità operative; per i dati ospitati servono comunque un piano di esportazione, importazione e ripristino.

Quelli indicati sono prezzi di listino dei VPS, non un consiglio di dimensionamento valido per ogni app Deno. Nella decisione vanno inclusi spazio per i backup, monitoraggio e tempo di gestione. Un server già disponibile può evitare un nuovo abbonamento di hosting, pur richiedendo lavoro di manutenzione.

Che cosa succede a Deno KV e cron?

Deno KV può usare un percorso locale persistente per il database, con SQLite come motore sottostante nella CLI. Questa scelta può conservare una parte maggiore dell’API KV rispetto al passaggio al servizio di storage di un altro fornitore. Non copia però i record ospitati, non ricrea un’infrastruttura distribuita e non rende persistente il filesystem effimero di un container. Esporta i dati, importali con una procedura definita, monta uno storage persistente e verifica di poter ripristinare un backup. Documentazione di Deno KV.

La stessa distinzione vale per la pianificazione. Nella CLI, Deno.cron conserva lo stato di esecuzione in memoria e ogni processo ha un insieme indipendente di attività. Se esegui più repliche dell’applicazione, devi stabilire quale sia responsabile di una determinata attività pianificata o come debbano coordinarsi. Lasciare invariata la chiamata all’API non conserva il servizio di pianificazione gestito di Deploy. Comportamento di Deno cron.

Per una piccola app su un solo server, queste responsabilità possono essere accettabili. Per un’azienda che ha bisogno di infrastruttura ridondante e in cui nessuno vuole occuparsi di backup, patch o ripristino, un VPS dal canone contenuto può diventare una distrazione costosa.

workerd e celld seguono un altro percorso di self-hosting

L’annuncio di Cloudflare indica workerd e celld come opzioni di self-hosting già disponibili. Entrambi usano il modello di programmazione di Workers: si valutano quindi dopo un porting verso quel modello, senza aspettarsi che eseguano tutto il codice Deno esistente senza modifiche. Cloudflare riconosce inoltre che l’implementazione di Durable Objects in workerd autonomo ha un limite di scalabilità legato alla singola istanza e descrive l’integrazione in workerd di lavoro e idee provenienti da celld. Annuncio di Cloudflare.

Non attribuire a queste opzioni il prezzo di un nuovo abbonamento gestito o un piano gratuito inventato. Il budget è quello dell’infrastruttura e della gestione che fornisci tu. Per un team che deve migrare in tempi stretti, contano le capacità disponibili oggi e un piano di ripristino che sappia eseguire; il lavoro di integrazione futuro non sostituisce queste decisioni.

Deno in self-hosting può essere una soluzione di passaggio, ma, vista la finestra di supporto annunciata, serve anche un piano per la manutenzione del runtime nel lungo periodo.

Scegliere in base a ciò che esegue il progetto

La scelta cambia quando la parte più difficile da trasferire è lo stato anziché il codice. Valuta l’impegno in base alle modifiche individuabili: basso significa adattare un handler o la build lasciando invariato lo stato esterno; medio aggiunge l’adattamento delle interfacce del runtime o la riscrittura dell’API di storage; alto comprende riprogettazione delle transazioni, trasferimento delle attività in coda o nuove responsabilità operative. Anche una piccola app può richiedere una migrazione impegnativa se il suo corretto funzionamento dipende da questi comportamenti.

Per le funzioni TypeScript senza API specifiche di Deno, parti da Workers. Conserva il comportamento di richieste e risposte, poi adatta il punto di ingresso e il deployment. Netlify diventa più interessante quando le funzioni modificano le richieste di un sito; Supabase quando operano soprattutto sul suo database. Vercel prevale quando il framework dell’applicazione è già il motivo del trasferimento. Un handler senza stato è di solito il caso meno impegnativo su tutte queste piattaforme.

Per Deno KV, scegli prima il modello di storage. Contenuti letti molto spesso possono adattarsi a Workers KV o Netlify Blobs. I record transazionali orientano verso D1, Postgres o un altro database progettato attorno alla regola da garantire. Il coordinamento può orientare verso Durable Objects. A una piccola utility può bastare SQLite su Val Town. Un KV locale in self-hosting conserva più codice, ma ti trasferisce la responsabilità della persistenza e del ripristino. Considera ogni migrazione da un KV ospitato almeno di impegno medio, finché l’inventario di transazioni e indici non dimostra il contrario.

Per i cron, confronta le condizioni di esecuzione. Un report giornaliero e un’attività che interroga spesso un servizio hanno requisiti diversi. Workers Cron Triggers è la prima opzione gestita da valutare; Val Town è interessante per un’attività circoscritta; Supabase Cron si adatta alla manutenzione del database; Netlify Scheduled Functions alle attività associate a un sito. Il vincolo giornaliero di Vercel Hobby lo esclude per le attività frequenti. Registrare di nuovo una pianificazione richiede poco lavoro; evitare effetti sovrapposti può richiederne molto di più.

Per le code, trasferisci insieme i messaggi in attesa e il consumer. Cloudflare Queues e Supabase Queues sono destinazioni esplicite; Vercel Queues aggiunge un’opzione in beta. La migrazione comprende identità dei messaggi, nuovi tentativi, conferme di elaborazione e attività già in attesa. Un semplice timer non basta. L’impegno è alto quando le attività in coda corrispondono a prestazioni già pagate dai clienti.

Per i siti statici, trasferisci i file generati prima di adattare codice server che potrebbe non servire. Workers Static Assets e Netlify sono candidati diretti; Vercel va considerato quando il framework del sito trae vantaggio dal suo flusso di lavoro. Controlla separatamente reindirizzamenti, header, moduli, autenticazione e rotte dinamiche. Trasferire semplici file statici richiede meno lavoro che migrare un sito che genera risposte personalizzate a ogni richiesta.

Migrare Deno KV conservando il comportamento dell’applicazione

Pubblicare il codice e migrare i dati hanno criteri di successo diversi. Il codice funziona quando risponde correttamente; la migrazione riesce quando la destinazione conserva i record e le regole che rendono corrette quelle risposte.

Prima dell’esportazione, censisci le funzionalità KV utilizzate: chiavi composte tipizzate, scansioni per prefisso, scadenze, indici secondari, controlli ottimistici delle versioni, aggiornamenti atomici e watcher. La guida KV di Deno spiega perché un insieme di chiavi può incorporare più logica applicativa di quanto faccia pensare una semplice esportazione di oggetti.

Un indice dei nomi utente è un buon esempio. Se l’app conserva un record utente e un’associazione dal nome utente al relativo record, copiarli entrambi non basta. Il nuovo percorso di scrittura deve conservarne la relazione e rifiutare aggiornamenti in conflitto. Allo stesso modo, un timestamp che prima faceva scadere una sessione richiede una regola esplicita nella destinazione: importarne soltanto il valore può lasciare la sessione valida troppo a lungo.

Per le code, mantieni un elenco separato delle attività in attesa, completate e fallite, quando la sorgente rende disponibili queste informazioni. Decidi se far esaurire la coda al vecchio consumer prima del passaggio oppure trasferire le attività con identificatori che ne rendano sicura la riesecuzione. Idempotenza significa che ripetere un’attività non ne ripete l’effetto applicativo. È la proprietà che impedisce a un nuovo tentativo di inviare più ricevute o a un messaggio di evasione ripetuto di generare lavoro duplicato.

1. 1

   Copiare definendo come gestire le scritture

   Esegui un backup della sorgente e decidi come gestire le scritture durante la copia. Per una piccola applicazione può bastare una breve sospensione delle scritture; una sincronizzazione più complessa richiede una riconciliazione dei dati. Evita che modifiche concorrenti vadano perse senza segnali tra esportazione e passaggio alla nuova piattaforma.

2. 2

   Verificare record e comportamento

   Confronta conteggi per tipo di entità, valori rappresentativi e codifiche delle chiavi. Prova invii duplicati, aggiornamenti in conflitto, scadenze e record mancanti con dati di test controllati. Verifica il risultato applicativo atteso, oltre alla risposta positiva della nuova API.

3. 3

   Trasferire insieme traffico e responsabilità delle attività

   Reindirizza le richieste solo quando lo stato di destinazione è pronto. Disattiva o trasferisci le vecchie pianificazioni e i consumer, così che le due piattaforme non producano lo stesso effetto. Ricrea in modo esplicito segreti e destinazioni dei webhook.

4. 4

   Monitorare e mantenere una procedura di ritorno praticabile

   Dopo il passaggio, monitora errori, attività fallite ed eventi applicativi. Conserva il backup della sorgente. Se la destinazione ha accettato nuove scritture, per tornare indietro serve un piano di riconciliazione dei dati: invertire la modifica DNS non basta.

Nella prossima sessione di lavoro, prepara un inventario e scegli la destinazione per l’operazione con stato più difficile da trasferire. Migra quell’operazione prima di rifinire il resto: farà emergere più rischi del trasferimento di un altro endpoint senza stato per il controllo di integrità.

Come sono state selezionate le alternative

Questi percorsi sono stati scelti in base ai carichi di lavoro di un’applicazione Deno Deploy: funzioni HTTP, stato persistente, attività pianificate, code e contenuti statici. Cloudflare viene prima perché Deno lo indica come destinazione per la migrazione. Netlify, Supabase e Val Town sono inclusi per l’esecuzione basata su Deno e l’adeguatezza a tipi diversi di applicazione; Vercel per il processo di deployment web; il self-hosting per il controllo del runtime.

Prezzi e funzionalità sono stati verificati sulle pagine pubbliche dei fornitori il 12 ottobre 2026. Le valutazioni dell’impegno descrivono le modifiche richieste dalle interfacce documentate. Non sono tempi di migrazione misurati, risultati di test di carico o affermazioni basate su prove effettuate dopo l’accesso alle piattaforme. I servizi cloud generalisti sono rimasti fuori dalla selezione perché aggiungere altri nomi non risolverebbe le decisioni centrali su runtime, stato e responsabilità delle attività.

Le scelte da evitare in questa migrazione

Evita di sostituire meccanicamente Deno KV transazionale con Workers KV. Sceglilo solo se il suo comportamento in lettura e scrittura è adatto ai dati. Uno storage economico non compensa la perdita delle garanzie di coerenza su cui si basa l’app.

Evita Netlify Edge Functions per elaborazioni in background intensive sulla CPU. Il budget delle richieste edge è un limite utile per progettare l’applicazione, non un ostacolo da aggirare sperando che un piano a pagamento cambi il modello di esecuzione.

Evita Vercel Hobby per un’app commerciale in produzione. Il listino lo riserva all’uso personale non commerciale. Anche i limiti dei cron lo rendono un termine di confronto inadatto tra piani gratuiti per attività frequenti.

Evita Val Town Free se il codice sorgente deve restare privato. L’idoneità del piano viene prima del volume di traffico. Evita anche di considerare Supabase Edge Functions la sostituzione predefinita per un sito statico tradizionale: scegli consapevolmente l’hosting del frontend.

Evita il self-hosting senza un responsabile del ripristino. Avviare il processo è la parte semplice. Qualcuno deve saper ripristinare i dati, riavviare i servizi e chiarire quale sistema di pianificazione sia responsabile dopo un’interruzione.

Domande da chiarire prima della migrazione

Quando chiude Deno Deploy?

L’annuncio indica una finestra operativa di sei mesi, senza fissare un giorno preciso. Fai riferimento a quella finestra, senza sostituirla con il periodo più lungo di manutenzione del runtime.

Posso continuare a usare Deno dopo aver lasciato Deno Deploy?

Sì. Netlify Edge Functions, Supabase Edge Functions e Val Town offrono un’esecuzione basata su Deno o compatibile con Deno, mentre un VPS o un container permettono di eseguirlo autonomamente. Ogni piattaforma gestita ha API e limiti propri. Mantenere Deno non conserva automaticamente il database KV ospitato, le pianificazioni o la coda.

Posso trasferire Deno KV direttamente in Cloudflare KV?

Solo adattando anche l’API e verificando che i requisiti di coerenza dell’applicazione siano compatibili con Workers KV. Controlli atomici, transazioni, indici e watcher di Deno KV richiedono sostituti espliciti. Per i record transazionali, valuta D1 o un altro database; per uno stato coordinato per singola entità, considera Durable Objects.

Quale piano gratuito può eseguire il mio cron job?

Controlla prima frequenza, limiti di esecuzione, riservatezza del sorgente e possibilità di uso commerciale. Val Town Free prevede un intervallo minimo di 15 minuti e un limite di esecuzione di 1 minuto. Vercel Hobby è limitato ad attività giornaliere e all’uso personale non commerciale. Workers Free ha un budget di CPU ristretto; Netlify e Supabase hanno quote condivise proprie di ciascun piano. La disponibilità di una pianificazione gratuita non dimostra che l’intera attività rientri nel piano gratuito.