Dove fare il deploy dei tuoi agenti AI: confronto tra le piattaforme per LangGraph e CrewAI
Ho confrontato le principali piattaforme per mettere in produzione sistemi agentici costruiti con LangGraph e CrewAI. Ecco cosa funziona davvero, cosa costa, e dove non andare a sbattere.
Mettere in produzione un agente AI non è come fare il deploy di una web app. L'ho capito nel modo peggiore: il primo agente che ho provato a deployare su Lambda ha smesso di rispondere dopo 15 minuti esatti, lasciando a metà un task che avrebbe dovuto completare un'analisi su centinaia di documenti.
Il problema non era il codice. Era che avevo scelto la piattaforma sbagliata per un tipo di workload completamente diverso.
Perché gli agenti rompono le assunzioni dell'infrastruttura classica
Una web app risponde in millisecondi. Un agente AI può girare per minuti o ore: chiama tool, aspetta risposte, aggiusta il piano, riprova. Ha bisogno di tenere lo stato tra uno step e l'altro (checkpointing), di ricevere e mandare output in streaming, e di non morire nel mezzo di un task se qualcosa si mette di traverso.
Questo esclude subito alcune categorie di infrastruttura e cambia radicalmente la valutazione delle altre. Il confronto che segue è il risultato di test e ricerca su LangGraph e CrewAI specificamente, ma i principi si applicano a qualsiasi framework agentico.
LangSmith Deployment: la scelta zero-friction per LangGraph
Se costruisci con LangGraph, la via più diretta è il deployment ufficiale di LangChain, integrato in LangSmith. Nessuna configurazione del checkpointer (usa Postgres gestito), nessuna gestione delle code, streaming nativo, e osservabilità integrata che ti mostra ogni step del grafo.
Il costo ha due componenti: il piano ($39/seat/mese per Plus) e il deployment runtime, che sulla produzione costa circa $0.0036 al minuto di uptime, quindi circa $155 al mese per un deployment sempre attivo, prima ancora di contare le run. Per task sporadici, i costi scendono significativamente.
Il limite è la dipendenza dal framework: funziona solo con LangGraph. Ma se stai già usando LangGraph, l'alternativa è replicare manualmente tutto quello che questa piattaforma fa per te, e il tempo risparmiato vale i costi.
Quando sceglierla: prototipazione rapida verso produzione con LangGraph, team che non vuole gestire infrastruttura.
CrewAI Cloud: tier gratuito utile, ma attenzione ai costi di scala
CrewAI ha la sua piattaforma gestita, AMP. Il tier gratuito include 50 esecuzioni al mese, poi $0.50 a esecuzione in overage. L'Enterprise ha pricing opaco (contatta le vendite), ma dalla documentazione emerge che include fino a 30.000 esecuzioni per cifre annuali nell'ordine dei centomila dollari.
Un dettaglio tecnico importante: CrewAI Cloud usa webhook per lo streaming degli eventi, non WebSocket veri. Funziona, ma la latenza è diversa e l'ordine degli eventi non è garantito (devi basarti sui timestamp). Per agenti che devono mostrare output in tempo reale all'utente, è un limite da considerare.
L'alternativa più usata in produzione con CrewAI è deployare il core open source su Render o Railway, mantenendo controllo completo sul costo.
Quando sceglierla: MVP e test con budget limitato (il tier gratuito è genuinamente utile), o ambienti enterprise con requisiti di compliance (FedRAMP, VPC dedicata).
Modal: la piattaforma più economica per compute puro
Modal è quello che uso quando il costo per run è il criterio principale. Non è una piattaforma agentica: è compute serverless Python con un'API molto pulita. Decori la tua funzione con @app.function() e Modal gestisce containerizzazione, scaling, e billing al secondo.
Il costo per una run da 30 secondi su CPU è circa $0.0016. Le GPU sono disponibili pay-per-second (H100 a $0.001/secondo). Il limite di esecuzione è 24 ore, che copre qualsiasi agente pratico. Scale to zero: se l'agente non gira, non paghi nulla.
Il rovescio: non c'è stato gestito. Devi collegare tu un Postgres esterno per il checkpointing di LangGraph, configurare tu l'osservabilità, gestire tu la coda se hai bisogno di run concorrenti. È raw compute, non una piattaforma.
Quando sceglierla: agenti con run frequenti e costo per esecuzione importante, team con esperienza infrastrutturale, workload che usano modelli locali su GPU.
Render e Railway: PaaS generalisti con buon supporto agli agenti
Render e Railway sono simili sulla carta, ma con differenze pratiche rilevanti.
Render ha documentazione ufficiale specifica per LangGraph, LlamaIndex e CrewAI, Background Workers senza limite di esecuzione (il punto chiave per gli agenti), Postgres con pgvector e Redis gestiti, e prezzi flat mensili prevedibili (da $7/mese per il servizio base). Il billing fisso significa che paghi anche quando l'agente è inattivo, ma elimina le sorprese.
Railway costa meno per iniziare ($5/mese), ha un'ottima developer experience e deploy da Git con zero downtime. Il limite: le richieste HTTP vanno in timeout dopo 15 minuti, quindi per agenti con run lunghe serve un pattern asincrono esplicito (API che accetta la richiesta, la mette in una coda Redis, worker separato che la esegue). Railway ha una guida ufficiale per questo pattern con sistemi multi-agente.
Entrambe le piattaforme richiedono di gestire tu il checkpointing (PostgresSaver di LangGraph puntato al tuo Postgres), ma è configurazione una-tantum.
Quando sceglierle: Render per semplicità e costi prevedibili con agenti sempre attivi; Railway per team che preferiscono billing per risorsa e hanno dimestichezza con il pattern asincrono.
AWS ECS/Fargate: potente, complesso, giustificato in enterprise
Su AWS, la prima cosa da sapere è che Lambda non va bene per gli agenti: il limite di 15 minuti è hardcoded e non si aggira. Il compute giusto è ECS Fargate, che gira container senza limite di tempo.
Il pattern produzione su AWS è: ALB per ricevere richieste, SQS per la coda, ECS Fargate per eseguire gli agenti, RDS o DynamoDB per lo stato, CloudWatch per i log. AWS ha un reference architecture ufficiale per multi-agent LangGraph su questo stack. Funziona molto bene, ed è la scelta naturale se sei già dentro AWS.
Il costo è competitivo (circa $0.04/vCPU-ora su Fargate, Spot riduce del 70%), ma la complessità operativa è significativa: stai componendo 4-5 servizi diversi, ciascuno con la propria configurazione, IAM, e superficie di errore.
Quando sceglierla: enterprise già su AWS, requisiti di compliance che richiedono deploy nella propria VPC, team con DevOps dedicato.
Google Cloud Run: ottimo, ma con un caveat importante
Cloud Run ha due modalità. Services (HTTP-triggered, serverless) ha un timeout massimo di 60 minuti per richiesta: sufficiente per molti agenti, ma un muro invalicabile per run più lunghe. Jobs (batch, run-to-completion) arriva fino a 7 giorni e non ha questo limite.
Per agenti in produzione, la combinazione giusta è Cloud Run Services per l'API di orchestrazione e Cloud Run Jobs per l'esecuzione vera e propria degli agenti. Supporta GPU (L4 disponibile in GA), ha un tier gratuito generoso, e il billing è pay-per-request in modalità serverless. Non ci sono guide ufficiali specifiche per LangGraph o CrewAI, ma entrambi girano senza problemi su qualsiasi container Python.
Quando sceglierla: team già su GCP o che vogliono integrazione nativa con Vertex AI e Gemini.
Fly.io Sprites: l'opzione più interessante per agenti intermittenti
A gennaio 2026 Fly.io ha lanciato Sprites, VM persistenti progettate esplicitamente per agenti AI. Il concetto è quello di un computer che "dorme": quando l'agente non è attivo, la VM si sospende e salva lo stato su disco. Quando arriva un nuovo task, riparte in pochi secondi da dove si era fermato.
Il costo è circa $0 in idle e $0.07/CPU-ora quando attivo. Una sessione intensa di 4 ore costa meno di 50 centesimi. Non c'è integrazione nativa con LangGraph o CrewAI, ma entrambi girano su qualsiasi processo Python.
Il modello di billing e il concetto di suspend/resume sono genuinamente diversi da qualsiasi altra piattaforma. Vale la pena tenerla d'occhio, soprattutto per agenti con utilizzo a picchi: chatbot aziendali, automazioni notturne, agenti che lavorano su richiesta.
Quando sceglierla: agenti intermittenti, utilizzo a picchi, team che vogliono provare un approccio architetturale diverso.
Self-hosted su Hetzner: il massimo controllo al costo più basso
Un CX32 su Hetzner (4 vCPU, 8 GB RAM) costa circa €9 al mese. Ci metti sopra Postgres, Redis, il server LangGraph via Docker Compose, un reverse proxy Nginx, e hai un ambiente di produzione completo per meno di €20 al mese totali.
Nessun timeout, nessun vendor lock-in, dati che non escono dall'infrastruttura tua. Il costo reale non è il compute, ma l'overhead operativo: backup, aggiornamenti, monitoring, SSL, scaling manuale se i carichi crescono. Per un singolo sviluppatore o un team piccolo, questo overhead può valere ampiamente il risparmio.
Quando sceglierla: workload con dati sensibili, budget infrastrutturale ridotto, team con competenze DevOps, o semplicemente quando non si vuole dipendere da nessun vendor.
Come mi oriento nella scelta
La mia euristica, basata sull'esperienza e sul confronto che ho fatto:
Se sto usando LangGraph e voglio andare in produzione senza perdere settimane di infrastruttura: LangSmith Deployment. Il costo è reale ma è tempo di engineering che non spendo.
Se sto usando CrewAI e il volume è basso o in rampa: il tier gratuito di CrewAI Cloud per i test, poi migrazione su Render con la guida ufficiale quando il volume giustifica il costo fisso.
Se il costo per run è critico e ho competenze tecniche: Modal, con Postgres esterno per il checkpointing e LangSmith per l'osservabilità.
Se sono già su AWS con un team DevOps: ECS Fargate con SQS, seguendo il reference architecture ufficiale di AWS per LangGraph.
Se voglio controllo totale e costi bassi: Hetzner con lo stack open source. Non è per tutti, ma per chi sa gestirla è la soluzione più efficiente.
Sto costruendo e deployando sistemi agentici su diversi stack in questo periodo. Se hai domande su un caso specifico o stai affrontando una scelta simile, trovami su LinkedIn.