IBM has made the Bob software-development agent generally available as a self-hosted backend on Red Hat OpenShift. An organisation can operate that backend on premises or in its own cloud account, preserve identity, audit logging and usage metering inside the cluster, and connect either to open-weight models on its own GPUs or to an approved external model service.[1][2][3]
This is a meaningful expansion for codebases that cannot be sent through a vendor-operated SaaS product. It is also a useful reminder that “self-hosted” describes a deployment pattern, not the complete answer to sovereignty. A system can run in a customer cluster while still depending on external models, vendor updates, licensed components or administrators outside the organisation’s legal and operational control.
Three deployment paths
| Configuration | Where Bob runs | Where model inference occurs | Main control question |
|---|---|---|---|
| IBM cloud service | IBM-operated service | Supported cloud models | Are the service terms and data controls acceptable?Source 2 |
| Customer-managed backend with external model | Customer OpenShift cluster | Customer-approved cloud model account | Does code context leave the controlled environment, and under which agreement?Source 1Source 2 |
| Fully self-hosted / air-gapped | Customer OpenShift cluster | Supported open-weight model on customer GPUs | Can the organisation operate, secure, update and size the entire stack?Source 1Source 2 |
Data location is one layer of control
IBM says a supported self-hosted model configuration can keep code, development context and build artifacts within the customer-managed environment. In the hybrid route, however, model requests—including the code context they carry—go to the organisation’s own cloud-model account. That can satisfy a policy when the account and region are already approved, but it is not the same as an air-gapped deployment.[1][2]
A fuller sovereignty inventory
| Measure | Value | Context |
|---|---|---|
| Data path | Prompts, code, files, tool outputs and logs | Record what crosses each network and legal boundary. |
| Model control | Weights, provider, version and routing | A local application can still depend on a remote model or a vendor-controlled alias. |
| Software supply chain | Images, packages, plugins and updates | Self-hosting does not prove every component is inspectable or independently replaceable. |
| Identity and authority | Users, service accounts, tools and approvals | The operator needs to know who can make changes and what the agent can execute. |
| Telemetry and support | Audit logs, diagnostics and incident access | Operational data can create another path outside the environment. |
| Exit and continuity | Export, rollback and replacement plan | Sovereignty is weak if the organisation cannot move or recover without the vendor. |
Running the system creates new obligations
The fully self-hosted route transfers more responsibility to the customer. IBM’s documentation points to model-specific hardware sizing because requirements depend on quantisation, context length and concurrent developers. The customer must also operate OpenShift, GPUs, identity, storage, monitoring, upgrades, vulnerability response and capacity planning. Control and operational burden arrive together.[2]
A cloud service can still be the safer choice for a low-risk workload if it is updated quickly, monitored well and covered by an appropriate agreement. Conversely, an air-gapped deployment can remain insecure if its packages are stale, privileged accounts are poorly controlled or outputs enter production without review. The architecture should follow the workload’s threat model rather than a slogan.
Measure outcomes as well as control
IBM’s initial Bob launch reported adoption by more than 80,000 employees and a 45% average self-reported productivity gain among surveyed users. Those figures are vendor-reported and do not establish what a self-hosted customer will achieve. A production evaluation should track accepted changes, review effort, defects, policy violations, infrastructure cost and time to recover from a failed agent action.[4]
The stronger case for self-hosting is therefore specific: it enables AI-assisted development for workloads that were previously excluded by data-residency or network requirements. The larger claim—AI sovereignty—must be earned across the complete control stack. Keeping the code inside is necessary for some organisations; knowing everything else the system depends on is what makes that control real.
Sources & further reading
- IBM Bob expands to self-hosted environments for sensitive and mission-critical enterprise software IBM · 30 Sep 2026 · Accessed 9 Oct 2026
- Run Bob on your own infrastructure IBM Bob · 1 Oct 2026 · Accessed 9 Oct 2026
- IBM introduces self-hosted deployment for IBM Bob IBM Newsroom · 1 Oct 2026 · Accessed 9 Oct 2026
- Introducing IBM Bob: AI development partner from coding to production-ready software IBM Newsroom · 28 Apr 2026 · Accessed 9 Oct 2026