IBM announced self-hosted deployment for Bob on October 1, 2026, giving enterprise development teams a way to use its coding and modernization platform in customer-managed infrastructure. IBM says the option supports on-premises, private-cloud, sovereign-cloud and air-gapped environments, including organizations handling sensitive source code.
The product announcement, dated September 30, declares general availability. Self-hosted Bob can use local models or approved external services. For buyers, the useful question is which configuration meets their code-handling rules—and whether they can operate the infrastructure it requires.
Choose where inference runs
Installing Bob does not install a complete model-serving system. IBM’s model-serving guide describes endpoints on the same OpenShift cluster, on separate private inference infrastructure, or at public-cloud providers. Customers must supply that serving capacity; Bob connects to it.
IBM’s supported-model list gives these options as of October 1. The names below are compatibility entries, not a ranking of coding quality.
Inference route | Models listed by IBM | Decision for the buyer |
|---|---|---|
Customer-operated, including air-gapped | Mistral 3.5; NVIDIA Nemotron 3; Poolside Laguna S2.1 | Evaluate when code and context must stay within the approved environment. Budget model-serving hardware and operations separately. |
Provider-managed cloud inference | Claude Sonnet 5; Claude Opus 4.8; Gemini 3.7 Flash; OpenAI GPT5.6 Sol | Evaluate when external processing is allowed. Approve the endpoint, region and data-handling terms before connecting sensitive workloads. |
The current Model Gateway supports one core inference model at a time. IBM’s documentation rules out simultaneous core models; multi-model routing is a future plan. A mixed local/cloud estate therefore needs a supported workload-separation design, not an assumption that Bob already routes each task automatically.
The architectural implication: record where Bob runs, where inference happens, where context is stored and which systems its tools can reach. A private connection to a provider does not move that provider’s model into your cluster. For background on this distinction, see the earlier Claude Code self-hosted runner analysis; it covers a different product and deployment design.
Size the platform and model serving separately
IBM’s system requirements specify amd64 OpenShift workers and support OCP 4.20, 4.21 and 4.22. The compatibility table pairs Bob self-hosted 2.0.0 with IDE 2.2.0 and Shell 2.0.5. Check that combination before standardizing developer clients.
For Bob Core without optional add-ons, the same page gives a production reference with headroom of approximately 36.5 vCPU, 53.4 GiB RAM and 50 GiB persistent storage. This is a Bob workload footprint, not a complete cluster or inference budget. Model-serving GPUs, platform topology, availability requirements and add-ons need separate sizing.
Deployment also requires entitled release assets and container images. IBM separates the initial cluster-wide setup from the subsequent namespace-scoped application installation, so platform administrators can review the wider permissions first. Those steps are documented in the installation prerequisites.
Plan offline servicing, logging and version changes
An air gap changes the operating process. The installation guide describes internal image registries and offline update imports. Its deployment comparison marks telemetry disabled for air-gapped installations and enabled by default, but disableable, for connected ones.
Separately, usage-metering documentation says Bob reports an active-user total without identities, prompts, code snippets or behavioral data. Connected installations forward it daily; disconnected ones require manual export and upload. That narrow description of metering is not an inventory of every log, diagnostic or tool connection. Assign owners for approved imports and reporting exports.
Three current-release limitations matter to rollout planning:
Version changes: controlled in-place upgrades are unsupported. IBM recommends a fresh installation for a new release; hotfixes can be applied to an existing instance by rerunning the installer. Plan migration and recovery accordingly.
Admin visibility: the Admin UI lacks Activity Logs in this release. Service pod logs remain available through OpenShift.
Analytics: Bobalytics is not part of the self-hosted stack and requires a SaaS environment. Do not treat the general Enterprise feature list as a self-hosted feature matrix.
IBM also assigns security-event logging, audit logging and monitoring to the customer’s OpenShift and enterprise tooling in its prerequisites. Those responsibilities need an operating team, not just a successful installation.
Get a deployment-specific quote and package list
The public pricing page reserves on-premises and air-gapped deployment for Enterprise and directs buyers to sales. It does not publish a self-hosted price. Public individual-plan prices are not a quote for this deployment.
IBM’s launch announcement allows eligible licenses for supported models through bring-your-own-license arrangements. It also names optional Java Modernization, IBM i and IBM Z packages, subject to licensing and deployment requirements. BYOL does not mean arbitrary model support or included inference hosting.
The self-hosted entitlement guide separates installing premium workloads from granting users access and focuses on Z-related components. Buying a package or assigning a user entitlement is not evidence that its backend is running. Obtain a written package/version matrix for the intended environment, especially for disconnected use.
For a cost comparison, include Bob and model licenses, packages, platform and GPU capacity, any cloud usage, operating labor and code-review effort. Compare equivalent workloads against the same acceptance standard and include idle capacity. Enterprise pricing and workload-specific sizing remain unknown here, so the published evidence does not establish savings or a break-even point.
What to require before a production rollout
A useful acceptance plan should produce four concrete records:
Data-flow map. Identify developer clients, Bob services, inference and guardrail endpoints, repositories, tool integrations, logs, backups and support exports. Record allowed data classes and destinations, then verify the configured traffic paths.
Supported bill of materials. Fix the Bob/client/model/runtime versions, model-license eligibility, premium packages and capacity assumptions. Agree who supports each component and which party owns incident response.
Operations plan. Name owners for identity, certificates, image imports, reporting, audit collection, backup/restore and migration to the next release. Include recovery from unavailable inference endpoints.
Workload evaluation. Use approved repositories and predefined tasks. Record configuration, outputs, accepted changes, reviewer effort, failures and costs. For local-only use, include disconnected operation; do not assume a cloud-model result transfers to a local model.
IBM recommends frontier models for complex IBM Z work. That is vendor guidance, not a comparative benchmark. Teams considering air-gapped modernization should evaluate their actual language patterns and multi-file changes with the supported local model they intend to deploy.
Self-hosted Bob is worth evaluating when an organization needs controlled infrastructure and can operate the supported stack. If external inference is permitted, assess the hybrid configuration on its own terms. If it is prohibited, make local inference and verified data flows acceptance conditions—not conclusions drawn from the self-hosted label.
Methodology: This AI-assisted decision guide draws on IBM’s announcement and public documentation checked on October 1, 2026. Deployment recommendations are analysis of those sources. No installation, traffic capture, productivity test or customer outcome was independently measured for this article.