Capita di rado che un fornitore rilasci una funzione e nello stesso testo raccomandi alla maggior parte dei clienti di lasciarla stare. Anthropic lo ha fatto il 6 agosto 2026, aprendo la beta pubblica degli ambienti self-hosted per Claude Code con una premessa che vale più del titolo: per la maggior parte delle imprese resta consigliata l’offerta gestita, e chi imbocca l’altra strada deve mettere in conto personale tecnico dedicato a costruirla e mantenerla. Un mese dopo l’annuncio circola nelle valutazioni di adozione autunnali come se fosse la risposta alla domanda sulla riservatezza del codice sorgente, e la documentazione tecnica dice qualcosa di diverso.
Nelle infrastrutture si distingue da sempre il piano su cui gira l’esecuzione da quello su cui viaggia il contenuto, ed è la stessa distinzione che serve qui: il self-hosting porta il primo dentro la rete aziendale e lascia il secondo esattamente dov’era. Assomiglia alla stagione del cloud privato di dieci anni fa, quando la parola d’ordine era il controllo e la domanda giusta arrivava dopo la firma.
Indice degli argomenti:
Il codice resta in casa, la conversazione no
Una sessione cloud di Claude Code è qualsiasi sessione che non gira sul portatile dello sviluppatore: parte da claude.ai, dall’app mobile o desktop, dal terminale, oppure da una routine pianificata, e per impostazione predefinita viene eseguita sull’infrastruttura di Anthropic. In un ambiente self-hosted quella stessa sessione viene eseguita su macchine dell’organizzazione, dentro il perimetro di rete, accanto ai servizi interni.
Cosa resta effettivamente lì dentro lo dichiara la documentazione: il checkout del repository, gli artefatti di build, i segreti e ogni file che la sessione crea o modifica restano sulle macchine che l’azienda ha provveduto a fornire. Subito dopo arriva la parte che pochi hanno riportato, e che ribalta la lettura più diffusa: la conversazione, cioè i prompt, le risposte e i risultati degli strumenti, incluso il codice che il modello legge durante il lavoro, viene inviata ad api.anthropic.com per l’inferenza, e il transcript della sessione viene conservato perché la si possa riprendere da un’altra superficie.
Il piano di controllo, con l’orchestrazione delle sessioni, le code e l’interfaccia di claude.ai, continua a girare sull’infrastruttura di Anthropic. Quello che si sposta è l’esecuzione. Un runner interno preleva il lavoro dalla coda, clona il repository, avvia un processo figlio di Claude Code, e tutte le connessioni sono in uscita dalla rete aziendale verso Anthropic, che non apre mai un canale verso l’interno.
Ottima architettura dal punto di vista del firewall, poco rilevante rispetto alla domanda che molti responsabili tecnici si stanno ponendo, che riguarda dove finiscono le righe di codice proprietario mentre il modello ragiona su di esse.
L’inferenza non può più passare da Bedrock
Tre esclusioni dichiarate nella documentazione dicono a chi serve davvero questa funzione, e la prima ha un che di paradossale. Gli ambienti self-hosted non sono disponibili per le organizzazioni che hanno attivato la Zero Data Retention, cioè proprio quelle che hanno negoziato il regime di conservazione più stretto. Chi ha il requisito più severo sui dati resta fuori dalla funzione presentata come risposta ai requisiti sui dati.
La seconda esclusione pesa in modo specifico sulle imprese europee. Nelle sessioni self-hosted l’inferenza usa l’API Anthropic, il piano di controllo consegna a ogni sessione l’endpoint e la sessione si autentica con un token OAuth generato da Anthropic e limitato alla singola sessione, quindi l’inferenza non può essere instradata attraverso Amazon Bedrock, la piattaforma agentica di Google Cloud, Microsoft Foundry o un gateway LLM aziendale. Tradotto per un CIO italiano: nell’ambiente gestito da Anthropic un’azienda può far girare l’inferenza sul proprio tenant Bedrock in una regione europea, con il contratto cloud che ha già firmato e i controlli che ha già superato; portandosi l’esecuzione in casa, quella possibilità sparisce e il traffico di inferenza torna a essere una connessione diretta verso Anthropic. Chi si autoospita per motivi di conformità rischia di perdere per strada la leva di conformità che stava già usando.
La terza riguarda il perimetro funzionale, ed è la più prosaica. Le sessioni prendono i repository da GitHub, le sessioni di Claude Security e quelle di Code Review non vengono ancora instradate sugli ambienti self-hosted, e Claude Tag ci gira ma senza poter usare gli access bundle. Chi ha già costruito flussi su queste superfici scopre che il passaggio non è completo.
Un runner si aggancia a un solo proprietario
L’architettura ha tre pezzi e un’analogia esplicita: l’ambiente è una destinazione con un nome, creata dalle impostazioni di amministrazione di claude.ai, che raggruppa i runner; il runner è un processo di lunga durata che gira sulle macchine aziendali, e l’idea, scrive Anthropic, è la stessa di un runner di integrazione continua self-hosted; la sessione è il singolo compito avviato da uno sviluppatore. Chi ha già una flotta di runner GitLab o GitHub sa quindi con buona approssimazione a cosa sta andando incontro, immagine da costruire e mantenere compresa.
C’è però un vincolo di isolamento che cambia il dimensionamento, e che nell’annuncio commerciale resta in secondo piano. Un runner serve un solo proprietario alla volta: alla prima sessione che preleva si aggancia al proprietario di quella sessione, e da quel momento esegue soltanto lavoro suo, fino alla capacità configurata. Serve a evitare che il codice estratto da due sviluppatori diversi finisca sullo stesso disco, ed è una garanzia sensata. La conseguenza operativa la mette nero su bianco la documentazione: la dimensione minima della flotta è il numero di proprietari che ci si aspetta attivi contemporaneamente, contando utenti e agenti Claude Tag. La flotta non scala con il carico di lavoro, scala con il numero di persone che stanno lavorando nello stesso momento, che è una funzione di costo molto meno favorevole.
Da qui in avanti le scelte sono quelle classiche dell’infrastruttura. Si tengono accese un certo numero di runner, oppure si mette in piedi un orchestratore di autoscaling, un secondo processo da ospitare, che accende runner via via che le sessioni si accodano. Il ciclo di vita è pieno di dettagli che diventano incidenti se ignorati: il runner interroga la coda dando dieci secondi a ogni richiesta e quel polling fa anche da battito cardiaco, se smette per una sessantina di secondi il server rimette la sessione in coda per un altro runner, e un proxy che intercetta la richiesta rispondendo con una propria pagina produce una risposta che il runner non sa interpretare.
Chi pensa di risparmiare mettendo i runner su istanze spot deve passare il parametro che fissa l’orario di ritiro qualche minuto prima della revoca, altrimenti la macchina che sparisce senza segnale è indistinguibile da un crash e il turno in corso si perde.
Il costo del self-hosting non è nel listino
Sul consumo non cambia nulla: le sessioni in un ambiente self-hosted consumano l’utilizzo di Claude Code dell’organizzazione esattamente come quelle negli ambienti gestiti. Nessuno sconto per il calcolo messo a disposizione, nessuna riduzione del prezzo dei token. Si aggiungono le macchine, l’immagine dei runner, l’orchestratore, la gestione delle credenziali git, l’egress e le persone che tengono in piedi tutto questo, e Anthropic è esplicita nel dire che serve un team di piattaforma o di developer experience che se ne assuma la proprietà operativa.
Il conto ha senso solo se dall’altra parte c’è un valore che l’ambiente gestito non può produrre, esattamente come accadeva con il cloud privato, dove a guadagnarci erano le aziende con un vincolo reale di rete o di latenza e non quelle che compravano una rassicurazione. Le organizzazioni del programma di anteprima ci sono arrivate per ragioni misurabili. Le sessioni girano dentro la rete e raggiungono servizi interni, database e registry senza doverli esporre su internet; l’immagine del runner arriva con compilatori, SDK e CLI interni già installati, quindi ogni sessione parte pronta a compilare; i controlli di sicurezza e le policy di rete restano quelli aziendali.
George Jacob, senior engineering manager di Faire, racconta che la configurazione permette a Claude di generare pull request, aiutare a sistemare problemi di integrazione continua e reagire a eventi dei flussi di lavoro degli sviluppatori, con capacità di calcolo che segue la domanda.
Sono tutti benefici di accesso e di ambiente, nessuno riguarda la confidenzialità di quello che il modello legge, e sui tavoli dove si discutono queste adozioni la confusione tra le due famiglie di vantaggi è la cosa che vedo più spesso, quasi sempre perché la delibera cita la parola conformità senza specificare quale requisito.
Quando un database non può uscire dalla rete
Il criterio di scelta si può ridurre a una domanda sola, che conviene porsi prima di aprire un ticket al team di piattaforma: il valore atteso viene dal fatto che la sessione raggiunge qualcosa che sta dentro la rete, oppure dal fatto che qualcosa non deve uscirne? Nel primo caso il self-hosting è la risposta corretta e il costo è giustificato, perché un agente che deve interrogare il database di staging, tirare pacchetti dal registry interno e girare contro un servizio non esposto non ha alternative pulite. Nel secondo caso si pagano infrastruttura e presidio per un risultato che non si ottiene, dato che prompt, risposte e risultati degli strumenti continuano a viaggiare verso l’inferenza.
Restano due verifiche preliminari che fanno risparmiare riunioni. La prima: se un team lavora solo da terminale e da ambiente di sviluppo integrato, non c’è niente da configurare, perché quelle sessioni girano già sulla macchina dello sviluppatore. La seconda riguarda chi vuole semplicemente pilotare da telefono una sessione avviata sul proprio computer, che è una funzione diversa, disponibile anche sui piani individuali, e non richiede alcuna flotta.
Rispetto al cloud privato, che questa vicenda ricorda da vicino, c’è un vantaggio di partenza. Gli ambienti self-hosted di Claude Code hanno il pregio raro di dichiarare per iscritto i propri limiti, dalla Zero Data Retention esclusa all’inferenza che non passa dai gateway, e la documentazione tecnica di un fornitore, letta prima della delibera invece che dopo, resta lo strumento di procurement più sottovalutato che abbiamo a disposizione.
Partecipa alla community