Cloudflare Come Piattaforma di Deploy: Perché Non È "Solo un CDN"

Cloudflare Come Piattaforma di Deploy: Perché Non È "Solo un CDN"

LE NOSTRE GUIDE

Pronto a imparare?

MarfCode · 10 aprile 2026 ·
Cloudflare edge computing deploy serverless performance

Cloudflare viene ancora percepita da molti come “quella cosa che metti davanti al sito per renderlo più veloce”. Questa percezione è diventata obsoleta. Nel 2025, Cloudflare è una piattaforma di compute distribuito completa — con frontend hosting, backend serverless, database, storage, autenticazione e sicurezza integrati — che compete direttamente con AWS, Vercel e Netlify su tutti i fronti che contano per una PMI.


L’Infrastruttura Edge: Cosa Significa in Pratica

L’idea centrale di Cloudflare come piattaforma di compute non è banale: invece di eseguire il codice in uno o pochi datacenter centralizzati, Cloudflare esegue il codice nei propri oltre 300 punti di presenza (PoP) distribuiti globalmente. Il tuo codice gira nel datacenter più vicino all’utente che fa la richiesta.

Il risultato pratico: un utente a Napoli che visita un sito deployato su Cloudflare Pages riceve la risposta dal datacenter di Napoli o Roma (o Milano), non da un server in Virginia o Irlanda. La latenza scende da 100–200ms a 10–30ms. Il Time to First Byte (TTFB) migliora di un ordine di grandezza rispetto a hosting tradizionale.

Questo non è un vantaggio marginale: per i Core Web Vitals e per la SEO, ogni millisecondo conta.


Cloudflare Pages: Il Deploy dei Frontend

Cloudflare Pages è la piattaforma di hosting per frontend statici e SSR. Si connette al repository Git (GitHub, GitLab), rileva automaticamente il framework (Astro, SvelteKit, Next.js, Nuxt, e molti altri), e costruisce e deploya ad ogni push.

Funzionalità chiave

Deploy atomici: ogni deploy è immutabile. Se qualcosa va storto, si torna alla versione precedente con un click — senza ripristinare backup, senza downtime.

Preview deployments: ogni branch o pull request riceve automaticamente un URL di preview. Il cliente può rivedere le modifiche in un ambiente identico alla produzione prima del merge. Questo cambia completamente il processo di revisione e approvazione.

Build cache: Cloudflare Pages cachea le dipendenze tra i build. Un sito Astro di media complessità che richiedeva 3 minuti di build scende a 45–60 secondi dalla seconda build in poi.

Edge rendering: SvelteKit e Astro in modalità SSR girano direttamente sui Cloudflare Workers — nessun “server” da gestire, nessun cold start problematico, scaling automatico a zero sotto traffico e infinito sotto picchi.

Piano gratuito generoso: 500 build/mese, deployment illimitati, bandwidth illimitata. Per quasi tutti i progetti PMI, il piano gratuito è sufficiente. Il piano Pro a 20$/mese aggiunge build concorrenti e analytics avanzate.


Cloudflare Workers: Il Backend Edge

Cloudflare Workers è il runtime serverless di Cloudflare. Esegue JavaScript/TypeScript (e WebAssembly) direttamente sull’edge, senza container, senza server, senza cold start significativi.

È il posto dove girano le API costruite con Hono — il framework che usiamo per il backend edge. La combinazione Hono + Workers produce API con latenza end-to-end nell’ordine dei 10–30ms a livello globale, senza infrastruttura da gestire.

Cosa si può fare con Workers

API e microservizi: endpoints REST o GraphQL che processano richieste, validano dati, interagiscono con database e storage. Il modello di pricing è per richiesta (i primi 100.000 al giorno sono gratuiti) — a differenza di un server che costa anche quando non fa nulla.

Middleware e trasformazioni: intercettare richieste prima che arrivino all’origine, modificare header, fare A/B testing, reindirizzamenti condizionali basati su geolocalizzazione o altri parametri.

Autenticazione e autorizzazione: Workers può verificare token JWT, gestire sessioni, proteggere endpoint — tutto a livello edge, prima ancora che la richiesta raggiunga il backend applicativo.

Scheduled tasks (Cron Triggers): eseguire codice a orari definiti — inviare email di reminder, sincronizzare dati, generare report. Senza un server sempre acceso.


Cloudflare R2: Storage Senza Costi di Egress

Cloudflare R2 è compatibile con l’API S3 di AWS (migrazione trasparente), ma con una differenza economica rilevante: nessun costo di egress — trasferire dati fuori da R2 verso Internet è gratuito.

Su AWS S3, il trasferimento dati in uscita costa 0.09$/GB. Per un sito con molte immagini o asset, questi costi si accumulano velocemente. R2 elimina questa voce di costo: si paga solo lo storage (0.015$/GB/mese) e le operazioni.

Per progetti con media e immagini abbondanti, R2 come storage per Directus (che lo supporta nativamente) è la scelta economicamente ottimale.


Cloudflare D1: Database SQLite sull’Edge

D1 è il database relazionale serverless di Cloudflare — SQLite distribuito e replicato sull’edge. Non è pensato per sostituire PostgreSQL su applicazioni enterprise: è pensato per dati che devono essere letti con latenza minima da qualsiasi punto del mondo.

Use case tipici: configurazioni applicative, sessioni utente, dati di profilo, catalogo prodotti read-heavy. Per questi pattern, D1 offre performance che un database centralizzato non può replicare.


L’Ecosistema Integrato: Il Vantaggio Vero

Il vero vantaggio di Cloudflare come piattaforma non è il singolo prodotto: è l’integrazione. DNS, CDN, WAF (Web Application Firewall), DDoS protection, compute (Workers), hosting (Pages), storage (R2), database (D1), analytics — tutto configurato da un’unica interfaccia, con un’unica API, senza dover orchestrare provider diversi.

Per una PMI, questo significa:

Meno complessità operativa: un pannello invece di cinque. Un account invece di quattro. Una fattura invece di sei.

Sicurezza per default: WAF, DDoS protection, SSL/TLS automatico, Bot management sono inclusi e attivi per default — non sono opzioni da aggiungere e configurare separatamente.

Pricing prevedibile: nessuna sorpresa di bandwidth a fine mese. Cloudflare non fa pagare il traffico in uscita come AWS.


Cosa Non Fa (Ancora) Bene Cloudflare

Va detto chiaramente: Cloudflare non è la risposta giusta per ogni scenario.

Database relazionali complessi: D1 è SQLite, non PostgreSQL. Per applicazioni con query complesse, transazioni pesanti o volumi di scrittura elevati, un database dedicato (Supabase, PlanetScale, Railway con PostgreSQL) è la scelta più appropriata.

Computazione CPU-intensive: Workers ha limiti di CPU time per esecuzione (50ms nel piano gratuito, fino a 30 secondi nel piano a pagamento). Elaborazione di immagini, generazione di PDF complessi, encoding video: non adatti a Workers.

Applicazioni stateful complesse: il modello serverless di Workers è stateless per design. Applicazioni che richiedono connessioni persistenti (WebSocket lunghi, streaming audio/video) richiedono soluzioni architetturali specifiche (Durable Objects) o approcci ibridi.


Il Nostro Approccio

In Marfcode, Cloudflare è la piattaforma di deploy di default per tutti i progetti frontend (Astro, SvelteKit) e per i backend API costruiti con Hono. Per backend che richiedono logica Python complessa (FastAPI) o database relazionale pesante, operiamo su VPS o container — ma il layer edge rimane Cloudflare.

L’obiettivo non è usare Cloudflare per tutto: è usare Cloudflare per quello che fa meglio, e scegliere lo strumento giusto per il resto.

Parliamo dell’architettura giusta per il tuo progetto


Articolo correlato: Hono vs Fastify vs FastAPI: come scegliere il framework backend | Astro e Directus: architettura headless ad alte performance