Cloudflare Workers pricing: il bundle non richiede più il piano Paid

Per chi valuta il Cloudflare Workers pricing, Cloudflare ha appena eliminato la dimensione del bundle dai motivi per scegliere Workers Paid. Il 4 settembre 2026, i precedenti controlli sulla dimensione compressa — 3 MB per Free e 10 MB per Paid — hanno lasciato il posto a un unico limite non compresso di 64 MiB per entrambi i piani: ora il budget di deployment va misurato sulla riga Total Upload di Wrangler, non su gzip.

Che cosa ha cambiato davvero Cloudflare

Il bundle di un Worker comprende il codice e i moduli di supporto che Cloudflare riceve durante il deployment. Wrangler, lo strumento a riga di comando di Cloudflare, prepara il pacchetto con esbuild per impostazione predefinita, include i pacchetti npm importati dal codice e ne indica la dimensione.

Fino al 4 settembre, Cloudflare comprimeva il bundle e lo rifiutava se il risultato superava 3 MB su Workers Free o 10 MB su Workers Paid. Il controllo sulla dimensione compressa è stato rimosso.

Adesso la piattaforma verifica un solo dato: il bundle non compresso non può superare 64 MiB. Il limite è identico per Free e Paid.

L'ultima colonna spiega l'intero meccanismo. Total Upload indica la dimensione non compressa. Wrangler continua a mostrare gzip come riferimento, ma Cloudflare non lo usa più per accettare o rifiutare un deployment.

Non conviene tradurre il cambiamento in un semplice moltiplicatore. I vecchi valori misuravano byte compressi in MB; quello nuovo misura byte non compressi in MiB. La quantità di codice aggiuntivo disponibile dipende da quanto si lasciano comprimere JavaScript, dipendenze e moduli binari del singolo progetto.

Cloudflare Workers pricing: cambia la scelta del piano da $5

La conseguenza economica immediata è circoscritta, ma utile. Workers Paid prevede un addebito minimo di $5 USD al mese per account. Se un team pensava di effettuare l'upgrade soltanto perché il bundle superava il precedente tetto di 3 MB del piano Free, quel motivo non esiste più finché Total Upload rimane entro 64 MiB.

Questo non rende equivalenti i due piani. Workers Free include ancora 100,000 richieste al giorno, 10 millisecondi di CPU per invocazione e 50 sottorichieste per invocazione. Workers Paid include 10 milioni di richieste e 30 milioni di millisecondi CPU al mese, consente 10,000 sottorichieste per invocazione e può arrivare fino a 5 minuti di CPU per richiesta, con un valore predefinito di 30 secondi.

La decisione di spesa diventa quindi più netta: si paga per traffico, CPU, sottorichieste e funzionalità riservate a Paid, non soltanto perché un bundle comprimibile superava la vecchia soglia del piano Free.

I team già su Paid per un uso reale in produzione non vedranno una riduzione diretta della fattura. Neppure chi aveva bundle ampiamente sotto il vecchio limite noterà cambiamenti nel workflow. Il vantaggio riguarda soprattutto i progetti che tagliavano codice, suddividevano servizi o passavano a Paid per ragioni legate alla dimensione del deployment.

Per il resto dei calcoli su account e runtime, la recensione completa di Cloudflare spiega come Workers si inserisce fra gli altri piani e costi a consumo di Cloudflare. I precedenti valori sul limite del bundle sono la parte sostituita dalla modifica di settembre.

Quattro tipi di build che ora diventano più semplici

Chi sviluppa un SaaS da solo può separare la scelta del piano da quella del framework

Immaginiamo un'applicazione full-stack distribuita su Workers Free. L'adapter di un framework, il codice per il rendering lato server e le dipendenze di produzione possono generare un bundle che, una volta compresso, supera il vecchio tetto del piano Free anche se il traffico dell'applicazione rientra ancora nelle sue quote.

Ora la build può essere valutata rispetto ai 64 MiB di Total Upload. Se rientra nel limite, la sola dimensione del bundle non impone più il minimo di $5 di Paid. Il vantaggio non è poter gestire gratuitamente la produzione a qualsiasi scala, ma convalidare la domanda prima di pagare per risorse di runtime che non servono ancora.

Un'agenzia può eliminare il controllo CI sbagliato

Il responsabile delle build di un'agenzia potrebbe aver copiato la vecchia soglia gzip in ogni repository dei clienti. Lasciare attivo quel controllo fa fallire le build in base a una regola che Cloudflare non applica più.

Va sostituito con un controllo sul Total Upload non compresso, scegliendo una soglia interna inferiore a 64 MiB per mantenere un margine. In questo modo i progetti dei clienti falliscono per il vincolo attuale della piattaforma, non per uno ormai superato.

Un team Rust o WebAssembly guadagna spazio, non un nuovo runtime

WebAssembly, spesso abbreviato in Wasm, permette a un Worker di eseguire codice binario compilato da linguaggi come Rust, Go o C. Cloudflare segnala che, in genere, i Worker Wasm sono più grandi degli equivalenti JavaScript perché il binario porta spesso con sé dipendenze di runtime aggiuntive.

La maggiore capacità di deployment lascia più spazio al modulo Wasm e al codice che lo accompagna. Wrangler supporta direttamente gli upload .wasm e .wasm?module. Ottimizzare la dimensione resta importante e Cloudflare consiglia wasm-opt per ridurre il binario.

Un team di piattaforma può abbandonare un'architettura nata come espediente

Un platform engineer che usa Workers Paid potrebbe aver diviso un servizio coerente, eliminato una dipendenza utile o realizzato un percorso personalizzato per i moduli esterni solo per restare sotto 10 MB compressi. Ora quella scelta merita di essere riesaminata.

Alcune suddivisioni devono rimanere perché definiscono responsabilità chiare o isolano i guasti. Se invece la separazione esisteva soltanto per il controllo sull'upload ormai ritirato, è diventata complessità priva di un requisito della piattaforma che la giustifichi.

Controllare il bundle reale prima del prossimo deployment

Non serve fare stime partendo dalla dimensione di node_modules, dalla directory dei sorgenti o dall'archivio generato separatamente dal framework. Basta eseguire il dry deploy di Wrangler dal progetto del Worker, così da creare lo stesso artefatto che Cloudflare riceverebbe davvero.

1. 1

   Compilare senza eseguire il deployment

   Eseguire il comando dry-run documentato da Cloudflare:

   wrangler deploy --outdir bundled/ --dry-run

   Wrangler compila il Worker e salva l'output in locale senza eseguire il deployment.

2. 2

   Leggere Total Upload

   Individuare Total Upload nell'output del comando. È la dimensione non compressa del bundle che Cloudflare confronta ora con 64 MiB. gzip può restare come dato diagnostico, ma non va usato per stabilire se la piattaforma accetterà o rifiuterà il deployment.

3. 3

   Aggiornare il budget nella CI

   Sostituire ogni regola sulla dimensione compressa di 3 MB per Free o 10 MB per Paid con una regola basata su Total Upload. Conviene fissare una soglia interna inferiore al massimo della piattaforma, così l'aggiornamento di una dipendenza non consumerà tutto il margine disponibile.

4. 4

   Controllare l'avvio nel deployment reale

   Al successivo deployment normale o upload di versione, registrare il valore startup_time_ms prodotto da Wrangler. Un bundle può rispettare il limite di upload e fallire comunque il controllo separato di Cloudflare sull'avvio.

L'errore più comune è continuare a guardare il valore gzip, visivamente più piccolo, perché in passato decideva l'esito del deployment. Ora non è più così: la voce che definisce il budget è Total Upload.

I limiti reali non sono aumentati di 64 MiB

I bundle più grandi possono richiedere più tempo per il parsing e l'inizializzazione. Il codice che svolge operazioni costose nello scope globale, quindi fuori dal gestore delle richieste, può ancora non superare la convalida e restituire Script startup exceeded CPU time limit con il codice di errore 10021. Restare sotto 64 MiB consente di oltrepassare il controllo sulla dimensione, ma non garantisce un avvio corretto.

La questione riguarda soprattutto framework pesanti e Wasm. Prima era spesso il vecchio limite a bloccare l'upload; quello nuovo consente a più codice di raggiungere il vincolo successivo, facendo emergere il comportamento della memoria e dell'inizializzazione.

Se un Worker è ancora troppo grande, la documentazione attuale propone tre soluzioni pratiche:

• Rimuovere i pacchetti e le dipendenze non utilizzati dal percorso eseguito in produzione.
• Conservare configurazione, asset statici e dati binari in Workers Static Assets, KV, R2 o D1 anziché nel bundle del Worker.
• Suddividere le funzionalità tra più Worker tramite Service Bindings.

Le chiamate tramite Service Binding non comportano una seconda tariffa per richiesta. Cloudflare addebita l'invocazione iniziale del Worker e il tempo CPU totale utilizzato da tutti i Worker coinvolti. La suddivisione è quindi uno strumento praticabile per gestire la dimensione, ma il confine di servizio aggiuntivo va comunque introdotto consapevolmente.

Che cosa fare lunedì

È il momento di intervenire se di recente un Worker non ha superato il vecchio controllo sulla dimensione, se il team ha ridotto le dipendenze del framework per restare sotto la soglia o se il bundle era l'unico motivo indicato per l'upgrade a Paid. Eseguire il dry deploy, annotare Total Upload e riesaminare quella decisione.

Si può invece aspettare se il Worker era già ben al di sotto del vecchio limite e la pipeline di deployment non contiene una soglia gzip codificata. Il runtime dell'applicazione non è cambiato.

È opportuno restare su Paid se lo giustificano richieste, tempo CPU, sottorichieste o un'altra funzionalità del piano. Un limite di upload Free più ampio non è un buon motivo per spostare un carico di produzione su un piano con quote operative inadeguate.

L'azione da fare lunedì è semplice: cambiare il controllo della build da gzip a Total Upload, poi scegliere il piano in base all'utilizzo e non alla dimensione del bundle.

Per ricevere il prossimo aggiornamento pratico sulla piattaforma, c'è la newsletter.