Cloudflare porta i container accanto ai Workers (beta pubblica)

Chi sviluppa applicazioni web conosce due mondi che finora è stato scomodo tenere insieme. Da un lato le funzioni “serverless”, programmi piccoli e leggeri che partono all’istante e reggono bene tanto traffico, ma con poca memoria e tempi di esecuzione stretti. Dall’altro le applicazioni “vere”, quelle che hanno bisogno di un ambiente completo - un sistema operativo, librerie di sistema, un runtime specifico - e che di solito si impacchettano in un container. Il 24 giugno 2025 Cloudflare, uno dei maggiori operatori di rete e CDN al mondo, ha aperto la beta pubblica di un servizio che prova ad avvicinare questi due mondi: i Container, eseguibili accanto ai Workers e comandati dallo stesso codice.

Prima un ripasso: Worker e container

Vale la pena chiarire i due termini, perché è lì che sta la notizia.

Un Worker è un programmino che gira sui server di Cloudflare distribuiti nel mondo. È “serverless”: non c’è un server da amministrare, il codice viene eseguito vicino a chi fa la richiesta, parte in una frazione di secondo e scala senza sforzo. In cambio è volutamente limitato: poca memoria, poco tempo di CPU, un ambiente ristretto pensato per JavaScript o WebAssembly. Perfetto per smistare richieste, applicare regole, comporre risposte; poco adatto a un lavoro pesante e prolungato.

Un container è invece un modo di impacchettare un’applicazione insieme a tutto ciò che le serve per funzionare: il suo runtime, le librerie, i file di sistema. Il vantaggio è che gira uguale ovunque, indipendentemente dalla macchina sottostante. È il formato con cui oggi si distribuisce gran parte del software, dai backend agli strumenti a riga di comando.

Il limite storico è che i Worker, da soli, non potevano ospitare un container: per quello serviva un’infrastruttura separata, con le sue complessità. La novità è proprio questa: ora le due cose stanno sulla stessa piattaforma.

Cosa ha annunciato Cloudflare

In sintesi: si possono ora eseguire container accanto ai Workers, sulla rete globale di Cloudflare, senza doversi occupare di orchestratori, cluster o regioni. Il servizio è disponibile in beta pubblica per chi ha un piano a pagamento.

L’idea di fondo la descrive bene la stessa Cloudflare: si usa un Worker quando serve essere leggeri e scalabili; si usa un container quando serve più potenza e libertà. I due non sono in concorrenza, lavorano insieme. Il Worker resta la porta d’ingresso - riceve la richiesta, decide cosa farne - e quando c’è da svolgere un compito impegnativo la passa a un container.

Come si incastrano Worker e container

La parte interessante è che il container non si gestisce da un pannello a parte: lo si comanda dal codice del Worker. Un container viene descritto nel file di configurazione del progetto (wrangler.jsonc) indicando l’immagine da usare, e da lì il Worker lo può avviare, raggiungere e spegnere.

Sotto il cofano l’architettura si appoggia ai Durable Object, un altro mattone di Cloudflare che serve a coordinare stato e istanze in modo ordinato. Il meccanismo è semplice da capire: a ogni identificativo diverso passato al container corrisponde un’istanza isolata e dedicata. Serve un container per ogni utente, o per ogni lavoro? Basta usare un identificativo diverso e la piattaforma ne crea uno separato. È Cloudflare a scegliere in quali punti della rete far partire le istanze, con avvii nell’ordine di pochi secondi.

Anche il flusso di lavoro è pensato per essere corto. In locale si sviluppa con wrangler dev, che costruisce l’immagine del container automaticamente; per pubblicare si usa wrangler deploy, senza dover gestire a mano un registro di immagini separato.

// wrangler.jsonc, in forma semplificata
{
  "containers": [
    {
      "class_name": "MioContainer",
      "image": "./Dockerfile",
      "instance_type": "basic"
    }
  ]
}

A cosa serve

Gli usi tipici sono quelli in cui un Worker da solo non basta e finora si sarebbe dovuto tirare su un server dedicato:

Strumenti a riga di comando e lavori “batch”. Programmi già esistenti, magari scritti in un linguaggio qualsiasi, che elaborano qualcosa e restituiscono un risultato.
Elaborazione di media e dati. Convertire un video o un’immagine, trasformare file, eseguire pipeline che richiedono CPU, memoria e un disco vero: compiti che sforerebbero i limiti di un Worker, un po’ come succede quando un’applicazione ha bisogno di una GPU per l’inferenza AI e non basta più una funzione leggera.
Backend in qualunque linguaggio. Un’applicazione già impacchettata come container può girare così com’è, con un Worker davanti che fa da instradatore.
Ambienti isolati per codice non fidato. Dare a ogni utente un container separato, ad esempio per eseguire codice generato o inviato da terzi senza che si influenzino a vicenda. È uno scenario citato anche per gli agenti AI e i server MCP a cui si collegano, che spesso hanno bisogno di uno spazio isolato in cui operare.

Perché abbassa la barriera

Il punto pratico è qui. Far girare container in tante parti del mondo, oggi, significa in genere occuparsi di parecchia infrastruttura, la stessa che di solito si descrive e si versiona con strumenti di Infrastructure as Code: scegliere le regioni, mettere in piedi un orchestratore (spesso Kubernetes), configurare il bilanciamento, gestire la scalabilità e gli aggiornamenti. È un lavoro che richiede competenze specifiche e tempo continuo di manutenzione.

L’approccio proposto sposta questo peso sulla piattaforma. Non si scelgono le regioni: è la rete a decidere dove eseguire. Non si configura un cluster: si dichiara un container e lo si comanda da codice. Per chi ha un carico che oggi non entra in una funzione serverless ma non giustifica la gestione di un intero cluster, è un modo per stare nel mezzo con meno attrito.

Va detto con onestà che “meno infrastruttura da gestire” significa anche meno controllo fine e un legame più stretto con una singola piattaforma, lo stesso compromesso da mettere sul piatto quando si sceglie un provider cloud. È un compromesso, non un pasto gratis: conviene valutarlo caso per caso.

Come si paga e quali limiti ci sono

Il modello di costo è a consumo e a grana fine: si paga solo mentre il container è effettivamente in esecuzione, misurato a intervalli molto brevi (nell’ordine dei 10 millisecondi), con CPU, memoria e disco conteggiati separatamente. Dopo un periodo di inattività il container va in pausa da solo, così non si paga per tempo morto. Il piano a pagamento include una quota mensile; i numeri esatti sono sulla pagina dei prezzi.

Alla partenza sono previste tre taglie di istanza - indicativamente da 256 MiB fino a qualche GiB di memoria, con quote di CPU e disco crescenti - e, trattandosi di una beta, ci sono tetti complessivi per account. Sono limiti pensati per la fase di prova e destinati a crescere: Cloudflare ha indicato tra i lavori futuri istanze più grandi, numeri più alti e uno scaling automatico con instradamento sensibile alla latenza, oltre a un’integrazione più stretta con gli altri servizi della piattaforma (archiviazione, database, chiavi-valore).

A che punto è

Serve la solita prudenza. Si tratta di una beta pubblica: aperta a chiunque abbia un piano a pagamento, ma pur sempre una fase di prova, con limiti stretti e funzionalità ancora in evoluzione. Alcune cose che ci si aspetta da una piattaforma matura - lo scaling automatico, le istanze più capienti, alcune integrazioni - sono dichiarate come in arrivo, non come già presenti.

L’idea di fondo, però, è concreta e già sperimentabile: portare i container dove già girano i Workers, e comandarli con lo stesso codice, invece di tenere due infrastrutture separate. Per chi oggi fatica a incastrare carichi pesanti in un ambiente serverless, vale la pena provarla su un progetto piccolo, tenendo conto che è ancora una beta e che il conto va guardato con attenzione mentre si sperimenta.

# Cloudflare porta i container accanto ai Workers (beta pubblica)