Agenti AI self-hosted con Cursor: rete privata, costi e limiti

Con il cambiamento del 2 settembre 2026, Cursor sposta insieme il confine di sicurezza e la voce di costo infrastrutturale: con gli agenti AI self-hosted, il team può mantenere l’esecuzione degli strumenti su macchine sotto il proprio controllo, ma diventa responsabile di quei worker. Modello, pianificazione e ciclo dell’agente continuano invece a funzionare nel cloud di Cursor.

Agenti AI self-hosted: il runtime si divide

Un Cursor Cloud Agent è composto da due metà. Il ciclo dell’agente decide l’azione successiva e interroga il modello. L’esecuzione degli strumenti è invece la parte che modifica i file, lancia comandi nel terminale, apre un browser, comunica con un server MCP locale e raggiunge i servizi interni.

Cursor Self-Hosted Machines separa queste due metà. Cursor continua a gestire ciclo, inferenza, pianificazione, interfaccia e orchestrazione della sessione. Gli strumenti vengono eseguiti da un worker amministrato dal cliente.

Il worker può essere un laptop, una VM, un Mac, un pod Kubernetes oppure una sandbox fornita da un partner di integrazione. Apre una connessione HTTPS in uscita verso Cursor, riceve le chiamate agli strumenti, le esegue localmente e restituisce i risultati. Cursor non richiede né una porta in ingresso né un IP pubblico sul worker.

La ripartizione operativa è questa.

Cursor propone due modalità per i worker. My Machines collega una macchina all’account di una sola persona ed è indicato per una devbox o per un workflow personale circoscritto. I Team Pools sono code con un nome destinate ai team Enterprise. Ogni richiesta resta nel pool finché un worker disponibile non la prende in carico; ciascun worker del pool gestisce una sessione Cloud Agent alla volta.

Non si tratta di un modello Cursor on premise. È un runtime diviso, con la metà dedicata all’esecuzione sotto il controllo del cliente. Da questa distinzione dipende la compatibilità della funzione con le policy aziendali.

Agenti AI nella rete privata: cosa resta dentro e cosa esce

Il checkout completo, la cache di build e le credenziali locali alla macchina restano sul worker. Anche i comandi, le operazioni sul repository, le build e le chiamate ai servizi interni vengono eseguiti lì. Si può così evitare di copiare un intero repository in una VM di esecuzione gestita dal fornitore.

Per decidere, però, l’agente ha comunque bisogno di contesto. Durante una sessione, il worker invia a Cursor il contenuto dei file necessario all’agente, l’output del terminale, i diff, gli screenshot, i risultati MCP locali e i metadati di routing. Screenshot, video e riferimenti ai log possono inoltre essere caricati nello storage degli artefatti gestito da Cursor, così da comparire nelle pull request e nella dashboard.

È possibile bloccare l’host degli artefatti senza fermare l’agente, ma in quel caso gli artefatti non saranno più visibili nella pull request e nella dashboard. Si applica anche Privacy Mode: il codice inviato dal worker non viene usato per l’addestramento da Cursor o dai suoi provider di modelli. La sessione, tuttavia, non diventa offline.

Ecco la prima conseguenza per l’azienda. La revisione di sicurezza può approvare separatamente il luogo di esecuzione e l’elaborazione del modello, ma deve comunque autorizzarli entrambi.

Chi può usare Cursor self-hosted e cosa cambia

Un team backend aziendale con servizi interni

Un team backend può aver bisogno di un registry privato dei pacchetti, di un database di staging e di endpoint di servizio non raggiungibili da una VM gestita. Un Team Pool può operare sulla stessa rete controllata ed eseguire la build senza aprire una rotta in ingresso da Cursor.

Il vantaggio riguarda il controllo degli accessi, non una privacy automatica. Il team di piattaforma può continuare a usare le policy di rete e il secret store esistenti; il team di sicurezza può invece verificare con precisione quali risultati attraversano la connessione in uscita.

Un team iOS vincolato ai Mac

I Cloud Agent gestiti da Cursor funzionano su VM Ubuntu. Un team che necessita di hardware Mac per sviluppare su iOS può registrare i Mac come worker, concedere le autorizzazioni richieste per l’uso del computer e permettere a un agente di fare clic, digitare, acquisire screenshot o controllare il browser su quella macchina.

Il vantaggio è poter usare per l’agente remoto la stessa classe di hardware impiegata per la build. Il costo operativo è ben noto a chi gestisce una flotta di Mac per le build: divergenza delle immagini, autorizzazioni, disponibilità, pulizia e sostituzione restano a carico del team.

Un team di piattaforma con domanda irregolare di agenti

Un team di piattaforma può collocare Cloudflare Containers dietro un Team Pool. Il template di riferimento avvia un container isolato per ogni sessione presa in carico, usa un Durable Object come proprietario del container e può memorizzare nella cache gli snapshot del repository su R2.

Il pool rimane attivo anche quando non ci sono worker connessi, quindi la capacità può scalare fino a zero. Quando torna il carico, il controller prende in carico la richiesta e avvia un container. Il vantaggio è un’infrastruttura di calcolo proporzionata all’utilizzo, invece di una flotta sempre attiva.

Uno sviluppatore indipendente con una devbox persistente

My Machines è adatto a chi lavora su un progetto che dipende da strumenti o stato locali difficili da ricreare. Più agenti possono condividere la stessa macchina: è una comodità su un computer personale, ma anche un avvertimento per i carichi sensibili.

Il vantaggio è la rapidità di configurazione. Il rischio è costituito dai residui tra un’esecuzione e l’altra, perché Cursor non cancella e ricrea il laptop tra le sessioni. Directory di lavoro, credenziali, pulizia dei processi e integrità della macchina sono responsabilità dell’utente.

Configurazione Cloudflare pronta da eseguire

Il percorso Cloudflare è utile perché rende evidente il nuovo confine delle responsabilità. Richiede Cursor Enterprise, una chiave di account di servizio del team con ambito agent, un account Cloudflare Workers Paid con Containers e R2, Node.js 20 o successivo e Docker.

1. 1

   Registra un Team Pool

   Installa la CLI di Cursor, verificane il funzionamento, quindi collega un worker locale temporaneo affinché il pool compaia in Cursor.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Quando il pool compare, arresta il worker con Ctrl+C, quindi esegui unset CURSOR_API_KEY. Durante il test di Cloudflare, lascia spento il worker locale per evitare che prenda in carico per primo la richiesta.

2. 2

   Distribuisci il template di riferimento di Cursor

   Clona il template, installalo, accedi a Cloudflare e crea il bucket facoltativo per gli snapshot.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Salva le credenziali

   Inserisci la chiave dell’account di servizio Cursor nei secret del Worker. Aggiungi le credenziali Git solo se i container devono accedere a repository privati.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   Una chiave API personale di Cursor non funziona con un Team Pool. È l’errore di configurazione che più facilmente può sembrare un guasto dell’infrastruttura, perché il controller restituisce 401.

4. 4

   Imposta pool e capacità

   Nel file wrangler.jsonc, modifica CURSOR_POOL in cloudflare-test. Imposta containers[].max_instances sul numero massimo di sessioni simultanee che vuoi poter eseguire, non sul numero di sviluppatori del team.

   Il file di riferimento usa come valori predefiniti max_instances 10 e un container standard-1 con 0.5 vCPU, 4 GiB di memoria e 8 GB di disco. Le build reali potrebbero richiedere una configurazione più grande.

5. 5

   Distribuisci e osserva la prima esecuzione

   Esegui il deployment, quindi tieni aperte le viste del controller e dei container mentre avvii un Cloud Agent e selezioni il pool self-hosted.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   L’esecuzione iniziale programmata del controller può impiegare fino a cinque minuti per partire. Se una sessione presa in carico non si avvia, in genere il problema riguarda la capacità dei container, la clonazione del repository o le credenziali Git.

Agenti AI self-hosted: il costo si sposta, non scompare

I Cloud Agent gestiti da Cursor includono l’infrastruttura di esecuzione. Le Self-Hosted Machines continuano a utilizzare il modello selezionato al prezzo stabilito da Cursor, a cui si aggiunge il costo dei worker. I Team Pools richiedono inoltre un contratto Enterprise, con prezzo personalizzato.

Cloudflare mostra come si comporta questa voce aggiuntiva. Il prodotto Containers rientra nel piano Workers Paid da $5 al mese. Sono incluse 25 GiB-ore di memoria, 375 minuti-vCPU e 200 GB-ore di disco. Oltre tali soglie, la memoria costa $0.0000025 per GiB-secondo, la CPU attiva $0.000020 per vCPU-secondo e il disco allocato $0.00000007 per GB-secondo.

Prendiamo la configurazione standard-1 del template di riferimento e ipotizziamo 100 sessioni: ciascuna lavora per un’ora, sfrutta tutta la CPU disponibile mentre è attiva e attraversa poi la finestra di inattività di cinque minuti prevista dal template. Al netto dell’utilizzo incluso, il costo dei container per il mese è di circa $12:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

È un esempio di costo infrastrutturale, non il conto complessivo di Cursor. Non comprende l’utilizzo di Worker e Durable Object, log, egress, R2, contratto Enterprise, uso del modello e personale addetto alla manutenzione della flotta. Presuppone inoltre che sia sufficiente la configurazione più piccola del template. Un repository con compilazioni pesanti potrebbe richiedere un container più grande.

Spesso la decisione più onerosa non riguarda la tariffa al secondo, ma la policy sulla capacità mantenuta attiva. Il worker generico del pool di Cursor usa per impostazione predefinita una finestra di riconnessione di 3,600 secondi; il template Cloudflare la riduce invece a 300 secondi. Una finestra più lunga rende più rapidi i prompt successivi e mantiene attiva la fatturazione di memoria e disco allocati. Una finestra più breve riduce la spesa durante l’inattività, ma aumenta gli avvii a freddo.

Anche la capacità è responsabilità del cliente. Il template viene fornito con spazio per 10 container simultanei. La richiesta successiva resta in attesa o non parte quando la capacità scelta, il limite dell’account o l’host sottostante non sono disponibili. Cursor può instradare il lavoro verso un pool, ma non può creare capacità che non è stata predisposta.

Lo stesso vale per l’isolamento. Il template Cloudflare assegna a ogni sessione un container dedicato. Una macchina personale può eseguire più agenti sullo stesso host. Se la policy richiede una VM nuova, un disco cancellato, separazione tra tenant o un confine delle credenziali ripristinato dopo ogni esecuzione, spetta al team implementare e verificare quel comportamento.

Anche le patch entrano nel calendario operativo. Il team è responsabile dell’immagine di base, della CLI di Cursor, degli strumenti di build, dei certificati, delle dipendenze e del rollout. Su Cloudflare, distribuire una nuova immagine del container arresta i container in esecuzione: l’aggiornamento deve quindi attendere la fine delle sessioni attive oppure accettarne l’interruzione.

Cosa conviene fare ora

È il momento di agire se, già questa settimana, un Cloud Agent deve usare hardware personalizzato, un’immagine su misura o strumenti non raggiungibili tramite il networking gestito. Conviene partire da un pool circoscritto e da un repository a basso rischio. L’elaborazione del modello e i dati restituiti dagli strumenti devono rimanere nella revisione di sicurezza, perché spostare l’esecuzione non li elimina.

Meglio attendere se l’unico requisito è accedere a codice sorgente privato o a un servizio interno. Cursor consiglia di provare prima ambienti gestiti, controlli di rete, Tailscale, AWS PrivateLink o Cloudflare Tunnel, evitando così di assumersi la gestione di una flotta di worker. Con queste opzioni, ciclo di vita e isolamento degli host restano in capo a Cursor.

Non cambia nulla se i Cloud Agent gestiti rispettano già le policy e riescono a riprodurre la build. Il self-hosting non aggiunge nuove capacità al modello: cambia il luogo di esecuzione e trasferisce la responsabilità operativa.

L’azione concreta per lunedì è scegliere un repository rappresentativo, definire quali parti di codice, credenziali, output degli strumenti e artefatti possono attraversare il confine, quindi eseguire la stessa build su un agente gestito e su un pool self-hosted con limiti rigorosi. Vanno registrati il tempo in coda, le ore-container, le modifiche accettate, gli errori di pulizia e il tempo dedicato alla manutenzione dell’immagine. La flotta va approvata solo se il requisito di controllo giustifica quella seconda voce di costo.

Ricevi nella newsletter la prossima analisi operativa dei workflow AI.