Il deployment self-hosted guida la release di questo mese

A partire dal 24 settembre 2026, IBM Bob è disponibile in disponibilità generale per il deployment self-hosted. Il backend Bob gira su cluster Red Hat OpenShift gestiti direttamente dall'organizzazione, on-premises o nel proprio account cloud. Il modello è un frontier model proveniente da un servizio di modelli cloud già utilizzato dall'organizzazione, oppure un modello open-weight sui propri GPU. Gli sviluppatori continuano a usare lo stesso Bob IDE e Bob Shell che già conoscono. La release di questo mese aggiunge anche processi in background, un client MCP aggiornato e nuovi controlli per gli amministratori.

Il servizio cloud Bob rimane la scelta predefinita più adatta alla maggior parte dei team di ingegneria: nessuna infrastruttura da gestire, aggiornamenti automatici e un backend operato da chi lo ha sviluppato. Per molte grandi organizzazioni di ingegneria questa opzione predefinita non è disponibile, perché il loro codice sorgente non può lasciare l'infrastruttura che controllano. Nel rispetto delle norme sulla residenza dei dati, Bob può utilizzare un frontier model attraverso il proprio account cloud dell'organizzazione. Su una rete air-gapped, Bob usa un modello open-weight sui GPU dell'organizzazione stessa.

Deployment self-hosted

Cosa include un deployment self-hosted

Il deployment self-hosted impacchetta il backend Bob per Red Hat OpenShift. Include identity, l'inference gateway, l'audit logging e il metering dell'utilizzo, il tutto gestito da un operator che si occupa di installazione, aggiornamenti e operazioni di giorno 2. Bob gira come un workload ordinario in un namespace, quindi può condividere un cluster esistente con altre applicazioni.

Gli sviluppatori continuano a lavorare in Bob IDE e Bob Shell come prima. L'endpoint self-hosted viene solitamente distribuito tramite group policy, così i client si connettono al cluster interno senza alcuna configurazione da parte dello sviluppatore. L'agent harness sottostante è lo stesso che gira contro il servizio cloud.

I pacchetti premium funzionano anche in un deployment self-hosted: IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i e IBM Bob Premium Package for Z (PP4Z). Un amministratore Bob li assegna agli utenti nella stessa Admin UI del servizio cloud. PP4Z porta con sé componenti backend propri, tra cui Z Understand, e l'amministratore del cluster decide al momento dell'installazione se distribuirli.

Due modi per connettere un modello

Bob self-hosted si connette a un modello in uno di questi due modi.

Frontier model attraverso l'account cloud dell'organizzazione. Bob può usare frontier model tramite AWS Bedrock, Azure OpenAI, Google Vertex AI o qualsiasi altro servizio di modelli compatibile con OpenAI. Il backend Bob, l'identity, gli audit log e il metering rimangono sul cluster. Le richieste al modello, incluso il contesto del codice che trasportano, vengono indirizzate all'account cloud dell'organizzazione secondo gli accordi già in essere. Questa soluzione è adatta alle organizzazioni che hanno già accesso approvato a un servizio di modelli cloud ma hanno bisogno di mantenere tutto il resto sotto il proprio controllo.

Completamente self-hosted. Per le reti senza connessione in uscita, il modello gira sui GPU dell'organizzazione. Per questa soluzione sono supportati due modelli open-weight: NVIDIA Nemotron 3 Ultra e Poolside Laguna S 2.1. L'agent harness di Bob è stato ottimizzato e valutato su ciascuno di essi. Il dimensionamento dell'hardware segue le indicazioni di ciascun fornitore, poiché dipende dalla quantizzazione, dalla lunghezza del contesto e dal numero di sviluppatori serviti contemporaneamente. Un piccolo modello di guardrail filtra input e output su questa soluzione, e Bob IDE e Bob Shell lo rilevano automaticamente una volta configurato.

Un'installazione in due fasi

L'installazione è gestita da bobctl, il CLI di installazione di Bob per i deployment self-hosted, e si svolge in due fasi. La prima crea gli elementi a livello di cluster: definizioni delle risorse, permessi e l'operator. Richiede diritti cluster-admin e, nella maggior parte delle aziende, passa attraverso il processo di change review del team della piattaforma. La seconda fase installa Bob stesso in un namespace e richiede solo l'accesso a livello di namespace.

Questa separazione significa che il team della piattaforma esamina e approva il footprint a livello di cluster una sola volta. Dopodiché, il team responsabile di Bob può installarlo, aggiornarlo e riconfigurarlo senza detenere diritti cluster-admin né aprire un ticket per ogni modifica.

I cluster completamente air-gapped sono un percorso di installazione supportato. bobctl replica le immagini di Bob in un registry privato, incluso il caso in cui le immagini vengano scaricate su una macchina connessa, trasferite attraverso il gap e caricate dal lato isolato.

Un'installazione OpenShift su nodo singolo è sufficiente per un proof of concept. Il dimensionamento per la produzione e i prerequisiti sono trattati nella documentazione di installazione.

Identity attraverso la directory aziendale

Un deployment self-hosted include il proprio servizio di identity, basato su Keycloak, che può essere connesso all'LDAP o all'Active Directory dell'organizzazione. Una volta connesso, gli sviluppatori accedono con le proprie credenziali aziendali e l'accesso segue la directory: le persone aggiunte vengono provisionate in Bob, e quelle rimosse perdono l'accesso automaticamente. Le installazioni più piccole e i proof of concept possono gestire gli utenti direttamente nel servizio di identity.

Come ottenere Bob self-hosted

Il deployment self-hosted è gestito dalla rete commerciale. Per vedere una demo o avviare un proof of concept, contatta un rappresentante IBM o un Business Partner, oppure usa Contact Sales su bob.ibm.com. Il team di account configura l'entitlement per l'organizzazione, inclusi eventuali pacchetti premium.

Inizia con un proof of concept OpenShift su nodo singolo puntato verso un endpoint di modello già in uso nell'organizzazione, e connetti il Bob IDE di un team ad esso. La documentazione sul deployment self-hosted copre il percorso da lì alla produzione, inclusa l'installazione air-gapped, il backup e il ripristino.

Altro in questa release

Client MCP aggiornato alla v2

Il client MCP supporta ora la specifica MCP 2026-07-28, incluso il transport stateless Streamable HTTP, mantenendo la compatibilità con i server MCP 2025 Streamable HTTP e stdio. La gestione del protocollo OAuth passa al client.

Breaking change: Il supporto al transport HTTP+SSE è stato rimosso e Bob rifiuta le configurazioni HTTP+SSE all'avvio. I server MCP che usano ancora HTTP+SSE devono essere aggiornati a Streamable HTTP prima di aggiornare Bob.

Per gli amministratori

Group policy RequiredExtensions. La group policy che distribuisce l'endpoint self-hosted può ora installare anche estensioni VS Code. Gli admin elencano gli ID delle estensioni nella nuova policy RequiredExtensions, e Bob le installa dal marketplace all'avvio, senza alcuna azione richiesta allo sviluppatore. La policy usa gli stessi template ADMX/ADML, il mobile device management e i meccanismi dei file di policy che già governano le impostazioni di Bob.

Directory dei plugin. Skill, mode, file di regole e configurazione MCP possono ora essere collocati sotto .bob/plugins/<plugin-name>/ a livello di workspace, o ~/.bob/plugins/<plugin-name>/ a livello globale, e Bob li carica all'avvio. Un team può distribuire una mode personalizzata, le regole a cui fa riferimento, le skill che invoca e una configurazione MCP insieme come una singola directory di plugin. Il layout esistente a livello root continua a funzionare.

Per gli sviluppatori

Processi in background. Build, watcher, dev server e altri comandi a lunga esecuzione ora si avviano in background invece di bloccare la conversazione. Un indicatore nella vista chat mostra cosa è in esecuzione; cliccaci sopra per ispezionare l'output o arrestare il processo.

Recupero di pagine web (sperimentale). Bob può recuperare una pagina di documentazione, un riferimento API o un altro URL noto e leggerlo come Markdown o testo semplice. Abilita prima web_fetch in Settings → Chat.

Lifecycle hook di compaction. PreCompact viene eseguito prima della compaction del contesto e può bloccarla; PostCompact viene eseguito al termine. /compress nell'input della chat attiva la compaction manualmente.

Larghezza della chat configurabile. Settings → Chat → Appearance offre Default, Wide e Full width, e la scelta persiste tra le sessioni.

Altro in questa release

Gli eventi degli hook possono essere inviati a endpoint HTTPS. I gestori di hook HTTP sono ora configurabili nell'interfaccia Bob Settings.
watsonx Governance è ora disponibile nel Bob Marketplace.
Le domande di follow-up ora appaiono una alla volta invece che in gruppo.
I nomi dei server MCP vengono preservati nei tool ID, rendendo più facile risalire a quale server appartiene una determinata chiamata a un tool.
Il file watching e la discovery delle skill ora funzionano nei workspace Remote SSH.
I nomi di directory delle skill non validi mostrano un avviso all'avvio.

Prova l'ultima release

Prima di aggiornare, sposta qualsiasi server MCP ancora su HTTP+SSE verso Streamable HTTP. Poi avvia un dev server in una sessione e continua a lavorare mentre gira in background.

Per condividere la configurazione di un team, metti una mode personalizzata, le regole a cui fa riferimento e le skill che invoca sotto .bob/plugins/<plugin-name>/ e fai il commit della directory nel repository. Bob carica il plugin all'avvio per chiunque apra il workspace. Con web_fetch abilitato, punta Bob al riferimento API di una libreria prima di chiedergli di scrivere codice per quella libreria.