Cloudflare ha introdotto il supporto per l’esecuzione di Cursor Cloud Agents all’interno di Cloudflare Sandboxes, offrendo a sviluppatori e team di piattaforma la possibilità di utilizzare agenti AI per il coding mantenendo l’ambiente di esecuzione sotto il controllo dell’organizzazione. L’integrazione utilizza la funzione Self-Hosted Machines di Cursor: Cursor continua a gestire agent loop, inferenza, pianificazione e orchestrazione, mentre l’esecuzione concreta delle attività viene affidata a un worker selezionato dal cliente. Utilizzando Cloudflare Sandboxes, questo worker può essere eseguito all’interno di un ambiente isolato presente direttamente nell’account Cloudflare dell’organizzazione.
Il workflow utilizzato dagli sviluppatori non cambia. I task possono essere assegnati ai Cloud Agents dall’applicazione Cursor, dal sito web di Cursor o dall’app mobile, mentre Cursor continua a instradare il lavoro e a restituire progressivamente i risultati all’utente. A cambiare è invece il luogo nel quale vengono eseguite le operazioni richieste dall’agente. Le chiamate agli strumenti, comprese le azioni sul terminale, sul filesystem, sui repository e sul browser, vengono eseguite all’interno della sandbox Cloudflare controllata dal cliente, permettendo alle aziende di mantenere maggiore controllo sulla posizione e sull’accesso a codice sorgente, cache di build, credenziali e altri elementi sensibili dell’ambiente di sviluppo.
Ogni sessione assegnata all’integrazione viene eseguita in un ambiente isolato supportato da Cloudflare Containers. Le sandbox dispongono di un filesystem separato e vengono eseguite all’interno di container Linux dedicati, mantenendo il proprio stato durante il periodo di attività. Dal punto di vista dell’architettura Cloudflare, ciascuna sandbox è inoltre associata a un Durable Object, utilizzato per identificarne e gestirne il ciclo di vita. In questo modo più sessioni di agenti possono essere mantenute separate tra loro pur utilizzando la stessa infrastruttura Cloudflare.
L’integrazione adotta un modello di connettività outbound. Il worker Cursor esegue la Cursor CLI e apre una connessione HTTPS persistente verso il backend di Cursor, attraverso la quale vengono trasmesse le chiamate agli strumenti necessarie all’agente. Cursor non deve quindi aprire una connessione inbound verso la rete del cliente. Questa architettura consente alle organizzazioni di inserire gli agenti all’interno di ambienti con vincoli di rete più rigorosi senza dover esporre direttamente l’infrastruttura interna a connessioni provenienti dall’esterno.
Durante l’esecuzione in modalità self-hosted, repository, build cache e secret rimangono sulle macchine o negli ambienti controllati dal cliente. Alcuni dati necessari al funzionamento dell’esperienza Cursor continuano comunque a essere trasferiti: i frammenti dei file letti dal modello durante l’inferenza, insieme agli artefatti prodotti dai Cloud Agents, come screenshot, video e riferimenti ai log, possono essere caricati affinché siano successivamente visualizzabili nelle pull request e nelle dashboard. La separazione riguarda quindi soprattutto l’ambiente nel quale vengono materialmente eseguiti comandi e strumenti, non l’eliminazione di ogni flusso informativo verso l’infrastruttura Cursor.
Il supporto è rivolto sia ai singoli sviluppatori sia ai team enterprise. Un singolo utente può collegare un worker attraverso la funzione My Machines, mentre le organizzazioni possono creare self-hosted worker pool utilizzati come destinazioni nominate per il routing delle nuove conversazioni con gli agenti. Quando una nuova sessione viene avviata, questa può rimanere in attesa fino a quando uno dei worker appartenenti al pool non diventa disponibile e prende in carico l’attività.
I team possono creare pool differenti per diversi ambienti di esecuzione e utilizzare sistemi di orchestrazione per adattare la capacità alla domanda. L’orchestratore può rilevare la presenza di nuove sessioni in attesa, avviare capacità aggiuntiva quando necessario e rilasciarla al termine del lavoro. Il modello consente quindi di trattare gli agenti AI come workload elastici, evitando di mantenere continuamente attive risorse dedicate quando non vengono utilizzate.
Cloudflare mette inoltre a disposizione un template open source basato su Workers per predisporre l’integrazione. Il deployment configura un Cloudflare Worker, un namespace Durable Objects, un’applicazione Container, un binding verso un bucket R2 e un cron trigger. Il bucket R2 può essere utilizzato per conservare snapshot opzionali dei repository, mentre Worker e Durable Objects coordinano l’assegnazione e il ciclo di vita delle sessioni agentiche.
La configurazione richiede un piano Cursor Enterprise con Self-Hosted Machines abilitato e una chiave API di service account del team dotata dello scope necessario per gli agenti. Sul lato Cloudflare è necessario un account Workers Paid con accesso a Containers e R2. Per deployment e sviluppo locale sono inoltre richiesti Node.js 20 o versioni successive e un daemon Docker operativo. Le credenziali per l’accesso ai repository privati possono essere memorizzate come Worker Secrets, evitando di inserirle direttamente nel codice dell’applicazione.
L’integrazione permette anche di utilizzare la Cloud Agents API per collegare informazioni sullo stato delle Self-Hosted Machines e il routing dei pool a sistemi sviluppati internamente dall’organizzazione. Le aziende possono quindi inserire gestione della capacità, monitoraggio dei worker e assegnazione delle sessioni all’interno dei propri sistemi di automazione e delle infrastrutture DevOps già esistenti.
Il supporto per Cursor amplia il lavoro già svolto da Cloudflare nell’esecuzione controllata degli agenti AI. L’azienda aveva già integrato nella propria infrastruttura soluzioni come Devin Outposts e Claude Managed Agents e sta posizionando Cloudflare Sandboxes come livello di esecuzione per applicazioni agentiche che devono operare vicino al codice e ai sistemi aziendali pur mantenendo isolamento e controllo infrastrutturale. Nel caso dei Cursor Cloud Agents, la separazione è netta: Cursor rimane responsabile dell’intelligenza e dell’orchestrazione dell’agente, mentre Cloudflare fornisce l’ambiente nel quale vengono eseguite concretamente le operazioni richieste dal modello.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)