Self-hosted deployment leads this month's release

As of September 24, 2026, IBM Bob is generally available for self-hosted deployment. The Bob backend runs on Red Hat OpenShift clusters the organization operates itself, on premises or in its own cloud account. The model is either a frontier model from a cloud model service the organization already uses, or an open-weight model on its own GPUs. Developers keep using the same Bob IDE and Bob Shell they already know. This month's release also adds background processes, an updated MCP client, and new controls for administrators.

The Bob cloud service remains the right default for most engineering teams: no infrastructure to run, updates that arrive automatically, and the backend is operated by the people who built it. For many large engineering organizations that default is not available, because their source code cannot leave infrastructure they control. Under data residency rules, Bob can use a frontier model through the organization's own cloud account. On an air-gapped network, Bob uses an open-weight model on the organization's own GPUs.

Self-hosted deployment

What a self-hosted deployment includes

The self-hosted deployment packages the Bob backend for Red Hat OpenShift. It includes identity, the inference gateway, audit logging, and usage metering, all managed by an operator that handles installation, upgrades, and day-2 operations. Bob runs as an ordinary namespaced workload, so it can share an existing cluster with other applications.

Developers keep working in Bob IDE and Bob Shell as before. The self-hosted endpoint is typically distributed through group policy, so the clients connect to the internal cluster without any setup on the developer's side. The agent harness behind it is the same one that runs against the cloud service.

The premium packages work in a self-hosted deployment as well: IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i, and IBM Bob Premium Package for Z (PP4Z). A Bob administrator assigns them to users in the same Admin UI as in the cloud service. PP4Z brings backend components of its own, including Z Understand, and the cluster administrator decides at install time whether to deploy them.

Two ways to connect a model

Self-hosted Bob connects to a model in one of two ways.

Frontier models through the organization's cloud account. Bob can use frontier models through AWS Bedrock, Azure OpenAI, Google Vertex AI, or any other OpenAI-compatible model service. The Bob backend, identity, audit logs, and metering stay on the cluster. Model requests, including the code context they carry, go to the organization's own cloud account under the agreements it already has. This route fits organizations that already have approved access to a cloud model service but need everything else under their own control.

Fully self-hosted. For networks with no outbound connection, the model runs on the organization's own GPUs. Two open-weight models are supported for this route: NVIDIA Nemotron 3 Ultra and Poolside Laguna S 2.1. Bob's agent harness was tuned and evaluated against each of them. Hardware sizing follows each vendor's guidance, since it depends on quantization, context length, and the number of developers served at once. A small guardrail model screens inputs and outputs on this route, and Bob IDE and Bob Shell pick it up automatically once it is configured.

A two-stage installation

Installation is handled by bobctl, Bob's installation CLI for self-hosted deployments, and runs in two stages. The first creates the cluster-wide pieces: resource definitions, permissions, and the operator. It needs cluster-admin rights, and in most enterprises it passes through the platform team's change review. The second stage installs Bob itself into a namespace and needs only namespace-level access.

The split means the platform team reviews and approves the cluster-wide footprint once. After that, the team that owns Bob can install, upgrade, and reconfigure it without holding cluster-admin rights or opening a ticket for every change.

Fully air-gapped clusters are a supported install path. bobctl mirrors the Bob images into a private registry, including the case where images are downloaded on a connected machine, carried across the gap, and pushed from the isolated side.

A single-node OpenShift installation is enough for a proof of concept. Production sizing and prerequisites are covered in the installation documentation.

Identity through the corporate directory

A self-hosted deployment includes its own identity service, based on Keycloak, which can be connected to the organization's LDAP or Active Directory. Once connected, developers sign in with their corporate credentials and access follows the directory: people added to it are provisioned in Bob, and people removed from it lose access automatically. Smaller installations and proofs of concept can manage users directly in the identity service instead.

How to get self-hosted Bob

Self-hosted deployment is sales-led. To see a demo or start a proof of concept, reach out to an IBM representative or Business Partner, or use Contact Sales on bob.ibm.com. The account team sets up the entitlement for the organization, including any premium packages.

Start with a single-node OpenShift proof of concept pointed at a model endpoint the organization already runs, and connect one team's Bob IDE to it. The self-hosted deployment documentation covers the path from there to production, including air-gapped installation, backup, and restore.

More in this month's release

MCP client updated to v2

The MCP client now supports the MCP 2026-07-28 specification, including stateless Streamable HTTP transport, while retaining compatibility with MCP 2025 Streamable HTTP and stdio servers. OAuth protocol handling moves to the client.

Breaking change: HTTP+SSE transport support has been removed, and Bob rejects HTTP+SSE configurations on startup. MCP servers still using HTTP+SSE must be updated to Streamable HTTP before upgrading Bob.

For administrators

RequiredExtensions group policy. The group policy that distributes the self-hosted endpoint can now also install VS Code extensions. Admins list extension IDs in the new RequiredExtensions policy, and Bob installs them from the marketplace on startup, with no action required from the developer. The policy uses the same ADMX/ADML templates, mobile device management, and policy file mechanisms that already govern Bob's own settings.

Plugin directories. Skills, modes, rules files, and MCP configuration can now be placed under .bob/plugins/<plugin-name>/ at the workspace level, or ~/.bob/plugins/<plugin-name>/ globally, and Bob picks them up on startup. A team can ship a custom mode, the rules it references, the skills it invokes, and an MCP config together as one plugin directory. The existing root-level layout continues to work.

For developers

Background processes. Builds, watchers, dev servers, and other long-running commands now start in the background instead of blocking the conversation. An indicator in the chat view shows what is running; click it to inspect the output or stop the process.

Fetch web pages (experimental). Bob can fetch a documentation page, an API reference, or another known URL and read it as Markdown or plain text. Enable web_fetch in Settings → Chat first.

Compaction lifecycle hooks. PreCompact runs before context compaction and can block it; PostCompact runs after it completes. /compress in the chat input triggers compaction manually.

Configurable chat width. Settings → Chat → Appearance offers Default, Wide, and Full width, and the choice persists across sessions.

Also in this release

Hook events can be sent to HTTPS endpoints. HTTP hook handlers are now configurable in Bob Settings UI.
watsonx Governance is now available in the Bob Marketplace.
Follow-up questions now appear one at a time rather than in a batch.
MCP server names are preserved in tool IDs, making it easier to trace which server a given tool call came from.
File watching and skill discovery now work in Remote SSH workspaces.
Invalid skill directory names surface a warning at startup.

Try the latest release

Before upgrading, move any MCP server still on HTTP+SSE to Streamable HTTP. Then start a dev server in a session and keep working while it runs in the background.

To share a team setup, put a custom mode, the rules it references, and the skills it invokes under .bob/plugins/<plugin-name>/ and commit the directory to the repository. Bob picks the plugin up on startup for everyone who opens the workspace. With web_fetch enabled, point Bob at the API reference of a library before asking it to write code against that library.