IBM’s new self-hosted deployment puts the IBM Bob backend on a customer’s OpenShift cluster. It does not automatically put the AI model—or the code context sent to that model—inside the same network. In the hybrid configuration IBM describes, requests carrying code context go to the customer’s external model-service account. A fully disconnected deployment requires on-premises inference, customer GPUs, and an offline installation and update path. That distinction is the central procurement question behind IBM’s October 1 announcement.
IBM’s release blog says general availability began September 24, 2026. The U.S. newsroom announcement followed on October 1; a separate product announcement is dated September 30. As of October 2, IBM has published installation and sizing documentation, but the checked pages do not give a public self-hosted price or independent deployment results.
For an engineering or security buyer, “self-hosted” therefore needs a narrower definition than “nothing leaves our environment.” It identifies who operates Bob’s backend. Inference placement, telemetry, software supply, and day-to-day operations need their own answers.
The boundary depends on inference
Developers still use Bob IDE and Bob Shell, while the backend runs on a customer-operated Red Hat OpenShift cluster. IBM says identity services, audit logs, and usage metering are hosted there too. That gives the customer control of several operational components, but it is only part of the data path described in IBM’s installation overview.
Hybrid is customer-hosted, with external model calls
In IBM’s hybrid configuration, the customer hosts the backend but uses an external model service through its own account. IBM’s release description says those model requests include code context. A buyer should evaluate that model provider, its contract, and the request payload separately from the location of the Bob backend. Calling this arrangement “on premises” without identifying the external inference path would conceal the most important boundary for sensitive code.
The same caution applies to connected operation. The installation methods describe external image and update sources, and connected telemetry is enabled by default, although IBM says it can be disabled. The checked sources do not provide a complete field-by-field inventory of every prompt, artifact, identifier, or telemetry value in every configuration. Security review should ask for that map rather than infer it from the deployment label.
A real air gap moves inference and the supply path
IBM describes a fully disconnected configuration using an open-weight model on the customer’s GPUs. Its release blog names NVIDIA Nemotron 3 Ultra and Poolside Laguna S 2.1. Other IBM pages discuss models at different levels of detail, so those examples should not be read as a complete, versioned approval list. IBM’s model-serving guidance is the starting point for checking a proposed endpoint and its capacity.
An air gap also changes how software arrives. IBM’s documented offline paths use image mirroring or offline transfer and offline update bundles; the documented air-gapped setup has telemetry disabled. The practical implication is that the customer must supply a controlled registry and update process as well as local inference. A disconnected backend that still depends on a remote model endpoint would fail the stated goal of keeping code context within the customer’s environment.
| Deployment question | What IBM documents | Buyer check |
|---|---|---|
| Backend and control services | Bob backend, identity, audit logs, and metering run on the customer’s OpenShift cluster. | Confirm cluster ownership, access, retention, and backup. |
| Hybrid inference | Model requests carrying code context go to the customer’s external model-service account. | Review the provider and exact request data path. |
| Fully disconnected inference | An open-weight model runs on customer GPUs; images and updates follow offline paths. | Validate model support, GPU capacity, mirroring, and updates. |
| Telemetry | Connected installation enables it by default but allows disabling; documented air-gapped setup disables it. | Verify configuration and data fields in the intended mode. |
Size the platform, not just Bob Core
The published infrastructure figures are useful planning inputs, but they describe different scopes. IBM’s system requirements list a minimum Bob Core workload of 22.1 raw vCPU, 35.1 GiB of memory, and about 30 GiB of persistent storage. Its production reference for that workload is 28.1 raw vCPU, 41.1 GiB, and about 50 GiB. IBM recommends roughly 36.5 vCPU and 53.4 GiB when applying 25–30% headroom.
A separate nine-node reference cluster totals about 84 vCPU, 168 GiB, and 600 GiB. It is not a replacement label for the Bob Core figure: the Bob workload numbers exclude OpenShift and other platform overhead. IBM also says a single-node OpenShift installation can support a proof of concept. Neither that proof-of-concept option nor the production reference establishes customer-specific throughput, GPU needs, or total cost. These are vendor planning figures, not independent performance benchmarks.
IBM currently lists OpenShift Container Platform 4.20, 4.21, and 4.22 and requires amd64/x86_64 nodes for Bob workloads. A team with an existing compliant cluster may have a shorter path to evaluation than one that first has to establish the platform, storage, security controls, and model-serving capacity. That is our operational inference from IBM’s requirements, not a measured cost comparison.
The customer becomes the operator
The first installation stage requires cluster-admin privileges to review or apply cluster-scoped resources. Subsequent installation and management can use namespace-level permissions, according to IBM’s prerequisites. This distinction matters for a controlled rollout: the initial change is a platform governance event, while later routine work can be more tightly scoped.
IBM assigns OpenShift security logging, monitoring, and audit controls to the customer and says Bob does not supply security-event logging. The customer also has to plan model serving, backup, networking, updates, and—when disconnected—mirrored images and offline bundles. These tasks sit outside the simple question of where the Bob application pods run. A proof of concept should identify the owners of each task before the team treats a successful install as production readiness.
There is a credible argument for avoiding that work. IBM says its cloud service remains the default for most engineering teams because IBM operates the backend and delivers automatic updates. Self-hosting can give an organization more control over the backend and deployment environment, but it transfers infrastructure and operating responsibility. Whether that exchange is worthwhile depends on the organization’s data requirements and existing platform capability; the available sources do not establish a universal answer.
What to settle before a sales-led pilot
IBM says access to self-hosted Bob is sales-led and that an IBM account team provisions organizational entitlements. The checked public pages do not state the self-hosted price, minimum entitlement, support terms, or charges for optional Premium Packages. Those packages cover Java modernization, IBM i, and IBM Z and have separate applicable licensing or deployment requirements. A budget based only on Bob Core CPU and memory would omit model-service charges or GPUs, platform operations, and any package-specific terms.
The useful pilot questions are concrete: Which model endpoint will receive code context? What exact data leaves the cluster in connected or hybrid mode? Which approved models and versions work in the proposed offline mode? How will images, updates, logs, and backups move across the boundary? What throughput and latency does the chosen inference setup deliver for the team’s own workload? Those answers need contract and deployment evidence, not an assumption that the phrase “self-hosted” resolves them.
No relevant post-announcement first-person production deployment report or controlled independent benchmark was found in the research for this article. IBM’s dated launch and technical documentation establish that the option exists and describe its requirements; they do not establish independent performance, adoption, or a particular customer’s security outcome. Nor do the checked announcement pages establish a U.S. regulatory certification or region-specific availability terms.
The practical decision is between three boundaries, not two labels: a customer-operated Bob backend, an external model service chosen by that customer, or a fully disconnected stack that the customer also operates. IBM has documented the route to each. The buyer’s work is to match one route to its code-handling rules and capacity to run it.