Cloudflare Workers: cosa sono e come usarli

Le applicazioni aziendali devono servire utenti, clienti e collaboratori sempre più distribuiti, senza trasformare ogni nuovo progetto in un esercizio di gestione dei server. Cloudflare Workers nasce per rispondere a questa esigenza: permette di eseguire codice sulla rete globale di Cloudflare e di portare una parte dell’applicazione vicino alla persona che la sta utilizzando.

Workers non è soltanto un servizio per creare piccole funzioni. È il livello di elaborazione centrale della Cloudflare Developer Platform e può coordinare database, object storage, servizi stateful, applicazioni containerizzate e risorse statiche. In questo modo diventa possibile costruire un’infrastruttura virtuale senza amministrare direttamente macchine, sistemi operativi o cluster.

Questa guida spiega cosa sono i Cloudflare Workers, come funzionano e in quali scenari possono essere utili a un’azienda. L’obiettivo non è entrare nei dettagli della programmazione, ma fornire gli elementi necessari per valutarne vantaggi, limiti e impatto architetturale.

Cosa sono i Cloudflare Workers

Un Cloudflare Worker è un’applicazione serverless eseguita all’interno della rete Cloudflare. Il codice viene distribuito sull’infrastruttura edge e viene attivato quando riceve una richiesta o quando si verifica un evento previsto dall’applicazione.

In un’infrastruttura tradizionale, una richiesta deve raggiungere un server collocato in una specifica regione geografica. Con Workers, Cloudflare può eseguire il codice in una posizione vicina all’utente e ridurre il percorso che la richiesta deve compiere. L’azienda non deve scegliere una macchina, installare un sistema operativo o dimensionare manualmente un gruppo di server.

Un runtime basato su V8, non un server Node.js

Workers esegue JavaScript e TypeScript attraverso un runtime basato sul motore V8, lo stesso motore JavaScript utilizzato da Chromium. Non avvia un processo Node.js completo per ogni richiesta: utilizza invece ambienti isolati, chiamati isolate, che possono essere creati rapidamente e condividere in sicurezza le risorse della macchina sottostante.

Il runtime supporta gli standard del Web e una parte delle API di Node.js. La modalità nodejs_compat amplia la compatibilità e consente di utilizzare molte librerie dell’ecosistema Node, ma non rende Workers equivalente a un server Node.js tradizionale. Prima di migrare un’applicazione esistente è quindi necessario verificare le dipendenze utilizzate e le funzionalità richieste.

Edge computing: eseguire il codice vicino all’utente

Con edge computing si intende l’esecuzione del codice in punti della rete più vicini agli utenti, invece che esclusivamente in un data center centrale. Questo modello può ridurre la latenza e migliorare la qualità percepita soprattutto quando l’applicazione serve persone in Paesi o continenti diversi.

Non ogni operazione deve necessariamente avvenire all’edge. Un Worker può elaborare immediatamente una richiesta, applicare regole di sicurezza, consultare una cache oppure inoltrare il lavoro a un database o a un servizio centrale. Il vantaggio è poter decidere quali attività distribuire e quali mantenere nell’infrastruttura già esistente.

Come funzionano i Cloudflare Workers

Dalla richiesta dell’utente all’esecuzione del Worker

Quando una richiesta raggiunge Cloudflare, la piattaforma individua il Worker associato al dominio o al percorso richiesto. Il Worker può generare direttamente una risposta, modificare la richiesta, interrogare un servizio oppure recuperare contenuti da un’origine esterna.

Questo consente di usare Workers sia come backend completo sia come livello intermedio davanti a sistemi già esistenti. Un’azienda può, per esempio, introdurre autenticazione, controllo degli accessi, caching o trasformazione dei dati senza dover riscrivere immediatamente tutta l’applicazione.

Una piattaforma distribuita sulla rete globale Cloudflare

Il codice non viene associato a un singolo server gestito dal cliente. Cloudflare lo distribuisce sulla propria rete e gestisce automaticamente disponibilità, avvio delle istanze e capacità necessaria per rispondere al traffico.

Questo modello elimina molte attività operative, ma non elimina la necessità di progettare bene l’applicazione. Dati, consistenza, dipendenze esterne e posizione dei database continuano a influenzare le prestazioni complessive. Portare il codice vicino all’utente non rende automaticamente vicino anche un database ospitato in un’unica regione.

Cosa si può realizzare con Cloudflare Workers

API, backend e gateway applicativi

Workers può esporre API, gestire la logica di un backend, comporre dati provenienti da più fonti e applicare regole prima che una richiesta raggiunga i sistemi aziendali. Può essere utilizzato come gateway per uniformare servizi differenti e offrire al frontend un’interfaccia coerente.

Questo approccio è utile durante la modernizzazione di applicazioni legacy: il Worker può diventare un livello controllato tra i nuovi canali digitali e i servizi esistenti, permettendo una migrazione progressiva invece di una sostituzione immediata.

Autenticazione, reindirizzamenti e trasformazione delle richieste

Tra gli utilizzi più immediati ci sono la verifica delle credenziali, la gestione dei permessi, i reindirizzamenti, la personalizzazione delle risposte e la normalizzazione dei dati. La logica viene applicata prima che la richiesta raggiunga il server di origine, riducendo il carico sui sistemi centrali.

Applicazioni aziendali distribuite a livello globale

Workers è particolarmente interessante per portali internazionali, piattaforme SaaS, applicazioni multitenant e servizi utilizzati da sedi collocate in aree geografiche diverse. La stessa base applicativa può essere distribuita globalmente senza replicare manualmente una tradizionale infrastruttura in ogni regione.

Workers ed ecosistema Cloudflare

Il valore della piattaforma emerge soprattutto quando Workers viene combinato con gli altri servizi Cloudflare. Il Worker gestisce la logica applicativa e accede alle risorse attraverso collegamenti configurati esplicitamente, chiamati binding.

I binding tra Workers e servizi Cloudflare

Un binding rende una risorsa disponibile direttamente al codice del Worker. Può collegare un database D1, un bucket R2, un Durable Object, un servizio Hyperdrive o un Container senza esporre credenziali nel codice e senza dover costruire ogni integrazione come una normale API pubblica.

I binding trasformano Workers in un livello di coordinamento dell’infrastruttura. La configurazione definisce quali risorse può utilizzare l’applicazione, mentre Cloudflare gestisce autenticazione e instradamento interno.

Cloudflare R2 per file e object storage

R2 è il servizio di object storage compatibile con l’API S3 di Cloudflare. Può contenere immagini, documenti, backup, file generati dagli utenti e altre risorse non strutturate. Un Worker può leggere o scrivere questi oggetti attraverso un binding e applicare controlli di accesso prima di distribuirli.

R2 è interessante per applicazioni che trasferiscono grandi quantità di dati perché non applica le tradizionali tariffe di uscita dei dati verso Internet. Rimangono naturalmente da valutare costi di archiviazione, operazioni e architettura complessiva.

Cloudflare D1 e la scalabilità orizzontale dei database

D1 è un database SQL serverless basato su SQLite e integrato con Workers. Offre un modello relazionale familiare senza richiedere la gestione diretta di un server database. È adatto a portali, applicazioni gestionali, cataloghi, sistemi di configurazione e numerosi progetti SaaS.

È importante conoscerne i limiti di dimensionamento. Sul piano Free ogni database può raggiungere 500 MB, con 5 GB complessivi per account. Sul piano Workers Paid il limite è di 10 GB per singolo database, con una disponibilità complessiva normalmente pari a 1 TB per account. Questi valori sono sufficienti per molti progetti comuni, ma richiedono una progettazione consapevole nei sistemi più grandi.

D1 è pensato per scalare orizzontalmente attraverso più database di dimensioni contenute. In un’applicazione multitenant si può, per esempio, assegnare un database a ogni cliente, gruppo di clienti, utente o entità applicativa. Non è una regola obbligatoria: la suddivisione deve riflettere requisiti di isolamento, volume e carico.

Ogni singolo database D1 elabora le query in modo sequenziale. Distribuire i dati su più database permette quindi di distribuire anche il lavoro, mentre indici corretti e query efficienti rimangono essenziali per mantenere buone prestazioni.

Cloudflare Hyperdrive per collegare database esistenti

Non tutte le aziende possono o vogliono trasferire i dati su D1. Hyperdrive permette ai Workers di collegarsi a database PostgreSQL e MySQL esistenti, migliorando la gestione delle connessioni e riducendo l’impatto della distanza tra il codice distribuito e il database centrale.

È una soluzione utile quando si desidera adottare Workers mantenendo il database aziendale corrente. La piattaforma gestisce il pooling delle connessioni e può memorizzare nella cache i risultati delle query supportate, evitando di aprire una nuova connessione geografica per ogni richiesta.

Durable Objects per applicazioni stateful e realtime

I Workers ordinari sono stateless: due richieste successive potrebbero essere eseguite da istanze differenti e non devono dipendere dalla memoria lasciata dalla richiesta precedente. I Durable Objects introducono invece una forma di elaborazione stateful.

Un Durable Object è una tipologia particolare di Worker con un’identità globale e uno storage privato, transazionale e fortemente consistente. Le richieste destinate allo stesso oggetto vengono coordinate in una singola istanza. Le nuove classi possono utilizzare un database SQLite collegato direttamente all’oggetto, mantenendo elaborazione e dati vicini tra loro.

Questo modello è adatto a chat, documenti collaborativi, notifiche in tempo reale, sessioni condivise e giochi multiplayer. I Durable Objects possono agire come endpoint WebSocket e mantenere coordinate migliaia di connessioni. Con la WebSocket Hibernation API l’oggetto può uscire dalla memoria durante i periodi di inattività senza interrompere i client, per riattivarsi quando arriva un nuovo messaggio.

Cloudflare Containers per software e runtime completi

Cloudflare Containers permette di eseguire immagini Docker all’interno di macchine virtuali Linux. Le immagini possono essere gestite nel registry Cloudflare oppure provenire da Docker Hub, Amazon ECR e Google Artifact Registry.

I Container ampliano i casi d’uso oltre i limiti naturali del runtime Workers. Possono eseguire applicazioni scritte in altri linguaggi, software con dipendenze di sistema, elaborazioni che richiedono più memoria o CPU e componenti che non potrebbero funzionare, o funzionerebbero in modo poco efficiente, all’interno di un isolate V8.

Ogni richiesta pubblica raggiunge prima un Worker, che seleziona il Container e può agire come proxy o load balancer. Il Container viene gestito attraverso un Durable Object, responsabile di identità, instradamento, ciclo di vita e stato persistente associato all’istanza.

Il disco locale del Container è effimero: quando l’istanza viene arrestata e riavviata, riparte dal filesystem definito nell’immagine. I dati che devono sopravvivere vanno salvati esplicitamente nello storage SQLite del Durable Object, in R2 o in un database esterno.

Esiste anche una limitazione di rete importante. Gli utenti finali non possono aprire direttamente connessioni TCP o UDP non HTTP verso un Container. Per questo motivo la piattaforma non è attualmente adatta a esporre in modo convenzionale un server di posta SMTP, IMAP o POP3, che richiede connessioni TCP pubbliche su porte specifiche.

Costruire un’infrastruttura componendo i servizi Cloudflare

Un’applicazione può utilizzare Workers per le API e la logica, R2 per i file, D1 per i dati relazionali, Durable Objects per le interazioni realtime, Hyperdrive per raggiungere database esistenti e Containers per i componenti che richiedono un ambiente Linux completo.

Questa composizione consente di creare un’infrastruttura virtuale gestita tramite codice e configurazione. Non scompaiono le decisioni architetturali, ma diminuiscono le attività dedicate a server, patch, cluster e bilanciatori tradizionali.

Hosting di file statici e applicazioni Next.js

Pubblicare file statici con Workers Static Assets

Workers può distribuire HTML, CSS, JavaScript, immagini e altri file statici direttamente dalla rete Cloudflare. Il contenuto statico può convivere con la logica dinamica nello stesso progetto: la piattaforma serve i file quando esistono e coinvolge il Worker quando la richiesta richiede elaborazione.

Questo modello è adatto a siti aziendali, documentazione, portali e applicazioni frontend che necessitano solo di alcune API dinamiche. Consente di gestire una sola distribuzione senza mantenere separati il sito statico e il backend serverless.

Eseguire Next.js su Cloudflare Workers

Le applicazioni Next.js possono essere pubblicate su Workers attraverso l’adattatore OpenNext. Sono supportati rendering lato server, generazione statica, Incremental Static Regeneration, Server Actions e altre funzionalità comunemente utilizzate nei progetti Next.js moderni.

Prima di una migrazione è comunque opportuno verificare la compatibilità delle librerie Node.js impiegate dal progetto. Un’applicazione costruita pensando a un server Node tradizionale potrebbe richiedere adattamenti, soprattutto quando utilizza moduli nativi o accede direttamente al filesystem.

Quando usare Workers per il sito e quando per il backend

Per un sito prevalentemente informativo, file statici e poche funzioni dinamiche possono essere sufficienti. Per un portale autenticato, Workers può gestire API e autorizzazioni. Nei sistemi più articolati, Workers diventa il punto di ingresso che coordina più servizi specializzati.

La scelta non deve quindi essere tra sito statico e applicazione completa: la piattaforma permette di adottare una soluzione intermedia e di aumentare progressivamente la componente dinamica.

Vantaggi di Cloudflare Workers

Costi contenuti e scalabilità automatica

Il modello a consumo permette di iniziare con costi molto bassi e di pagare in relazione all’utilizzo. Non è necessario mantenere server sovradimensionati per assorbire picchi occasionali e la piattaforma aumenta automaticamente la capacità disponibile.

Minore latenza per utenti distribuiti geograficamente

Eseguire parte della logica vicino agli utenti riduce i tempi di risposta e rende più uniforme l’esperienza tra aree geografiche differenti. Il beneficio è particolarmente rilevante per applicazioni internazionali e API chiamate frequentemente.

Infrastruttura gestita da un operatore di rete globale

Cloudflare gestisce una delle reti più estese al mondo. Utilizzare Workers significa appoggiarsi alla stessa infrastruttura che offre servizi di connettività, sicurezza, protezione DDoS e distribuzione dei contenuti, senza doverla costruire internamente.

Distribuzioni rapide e ambienti coerenti

Codice e configurazione possono essere versionati e distribuiti insieme. Questo rende più semplice riprodurre gli ambienti, automatizzare i rilasci e ridurre le differenze tra configurazioni mantenute manualmente.

Un ecosistema integrato

Calcolo, database, storage, realtime e container condividono lo stesso modello di configurazione e sicurezza. Per un team IT questo può ridurre il numero di piattaforme da integrare e le credenziali da amministrare.

Svantaggi e aspetti da valutare

Curva di apprendimento iniziale

Workers richiede di ragionare in modo diverso rispetto a un server tradizionale. Il team deve comprendere isolate, binding, limiti di esecuzione, servizi distribuiti e caratteristiche dei diversi sistemi di persistenza. I vantaggi operativi arrivano dopo una fase iniziale di formazione e progettazione.

Compatibilità Node.js non completa

Molte API Node.js sono disponibili, ma Workers non è un processo Node completo. Dipendenze native, accesso persistente al filesystem e alcune librerie progettate per server tradizionali possono non essere compatibili. Containers offre un’alternativa, ma introduce un modello operativo e costi differenti.

Vendor lock-in e portabilità del codice

Il codice applicativo basato sugli standard Web può essere in parte portabile. Binding, Durable Objects, D1 e configurazioni specifiche della piattaforma sono invece integrazioni proprietarie. Se in futuro l’azienda decidesse di cambiare fornitore, una parte dell’infrastruttura e del codice dovrebbe essere riscritta.

Limiti da conoscere prima della progettazione

Ogni servizio ha limiti di dimensione, concorrenza, CPU, memoria o durata. Non sono necessariamente un problema, ma devono entrare nell’analisi iniziale. Progettare senza considerarli può rendere costosa una modifica successiva.

Cloudflare Workers vs AWS Lambda

Edge network e regioni cloud

AWS Lambda esegue normalmente le funzioni nella regione AWS selezionata. Cloudflare Workers nasce invece per distribuire il codice sulla rete edge. Workers tende quindi a essere interessante quando la latenza globale è prioritaria, mentre Lambda è naturale per applicazioni già profondamente integrate con i servizi regionali AWS.

Modello di esecuzione e tempi di avvio

Workers utilizza isolate V8 leggeri, mentre Lambda avvia ambienti di esecuzione più completi. Il modello di Workers favorisce avvii rapidi e distribuzione capillare; Lambda offre maggiore flessibilità per runtime, dipendenze e carichi che richiedono un ambiente server più tradizionale.

Costi, scalabilità ed ecosistema

Entrambe le piattaforme adottano modelli serverless e scalano automaticamente, ma prezzi e unità di fatturazione sono differenti. Il confronto deve includere non soltanto il costo della funzione, ma anche traffico, database, storage, osservabilità e competenze già presenti in azienda.

Quando scegliere Workers e quando scegliere Lambda

Workers è una scelta convincente per applicazioni distribuite, API a bassa latenza, logica vicina all’utente e progetti che utilizzano l’ecosistema Cloudflare. Lambda rimane spesso preferibile quando il progetto dipende da numerosi servizi AWS, richiede runtime non adatti a Workers o deve essere eseguito in una regione specifica.

Quando conviene usare Cloudflare Workers in azienda

Aziende con utenti o sedi distribuiti

La distribuzione edge offre il massimo valore quando clienti, dipendenti o partner accedono all’applicazione da aree geografiche differenti. Per servizi esclusivamente locali il vantaggio di latenza potrebbe essere meno significativo, anche se rimangono i benefici operativi del serverless.

API e servizi che richiedono bassa latenza

Gateway, autenticazione, personalizzazione, e-commerce, applicazioni SaaS e funzionalità realtime sono candidati naturali. Workers può anche proteggere e accelerare un’infrastruttura esistente senza sostituirla completamente.

Modernizzazione progressiva di applicazioni esistenti

Una migrazione graduale riduce il rischio. L’azienda può iniziare da un endpoint, da una funzione di sicurezza o da una nuova area applicativa, misurare risultati e costi e ampliare successivamente l’adozione.

Progetti in cui Workers non è la scelta ideale

Applicazioni strettamente legate a sistemi operativi specifici, software che richiede connessioni TCP o UDP pubbliche, workload molto intensivi o progetti totalmente dipendenti da un altro cloud possono richiedere soluzioni differenti. In questi casi Workers può ancora svolgere il ruolo di gateway, ma non necessariamente diventare l’intera infrastruttura.

Conclusioni: Cloudflare Workers è adatto alla propria infrastruttura?

Cloudflare Workers offre una combinazione interessante di elaborazione edge, costi contenuti, scalabilità automatica e integrazione con servizi gestiti. Può supportare sia una piccola funzione davanti a un sito sia un’applicazione completa composta da database, storage, componenti realtime e container.

La decisione deve considerare distribuzione degli utenti, competenze del team, dipendenze esistenti, requisiti di portabilità e limiti dei singoli servizi. Per molte aziende il percorso più efficace non consiste nel trasferire immediatamente tutto su Workers, ma nell’introdurlo dove latenza, automazione e riduzione della gestione infrastrutturale producono un vantaggio misurabile.

Con un’architettura consapevole, Workers può diventare il tessuto connettivo di una piattaforma digitale moderna. La semplicità operativa non elimina la progettazione: la rende più concentrata sulle esigenze dell’applicazione e meno sulla manutenzione dei server.