Self-Hosted-Deployment führt die Version dieses Monats an

Seit dem 24. September 2026 ist IBM Bob allgemein für Self-Hosted-Deployments verfügbar. Das Bob-Backend läuft auf Red Hat OpenShift-Clustern, die das Unternehmen selbst betreibt – on-premises oder im eigenen Cloud-Konto. Als Modell dient entweder ein Frontier-Modell aus einem bereits genutzten Cloud-Modell-Service oder ein Open-Weight-Modell auf eigenen GPUs. Entwickler nutzen weiterhin die gewohnte Bob IDE und Bob Shell. Die Veröffentlichung dieses Monats bringt außerdem Hintergrundprozesse, einen aktualisierten MCP-Client und neue Steuerungsoptionen für Administratoren.

Der Bob-Cloud-Service bleibt der passende Standard für die meisten Engineering-Teams: keine Infrastruktur zu betreiben, automatische Updates und ein Backend, das von den Entwicklern des Produkts betrieben wird. Für viele große Engineering-Organisationen steht dieser Standard nicht zur Verfügung, da ihr Quellcode die von ihnen kontrollierte Infrastruktur nicht verlassen darf. Unter Data-Residency-Vorgaben kann Bob ein Frontier-Modell über das eigene Cloud-Konto des Unternehmens nutzen. In einem Air-Gapped-Netzwerk verwendet Bob ein Open-Weight-Modell auf den eigenen GPUs des Unternehmens.

Self-Hosted-Deployment

Was ein Self-Hosted-Deployment umfasst

Das Self-Hosted-Deployment bündelt das Bob-Backend für Red Hat OpenShift. Es umfasst Identity, das Inference-Gateway, Audit-Logging und Usage-Metering – alles verwaltet durch einen Operator, der Installation, Upgrades und Day-2-Operationen übernimmt. Bob läuft als reguläre namespaced Workload und kann sich somit einen bestehenden Cluster mit anderen Anwendungen teilen.

Entwickler arbeiten wie gewohnt in Bob IDE und Bob Shell. Der Self-Hosted-Endpunkt wird typischerweise über Gruppenrichtlinien verteilt, sodass sich die Clients ohne jegliche Einrichtung auf Entwicklerseite mit dem internen Cluster verbinden. Das dahinterliegende Agent-Harness ist dasselbe, das auch mit dem Cloud-Service läuft.

Die Premium-Pakete funktionieren auch im Self-Hosted-Deployment: IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i und IBM Bob Premium Package for Z (PP4Z). Ein Bob-Administrator weist sie Benutzern in derselben Admin-UI wie im Cloud-Service zu. PP4Z bringt eigene Backend-Komponenten mit, darunter Z Understand, und der Cluster-Administrator entscheidet bei der Installation, ob diese bereitgestellt werden sollen.

Zwei Wege zur Modellanbindung

Self-Hosted Bob verbindet sich auf zwei Arten mit einem Modell.

Frontier-Modelle über das Cloud-Konto der Organisation. Bob kann Frontier-Modelle über AWS Bedrock, Azure OpenAI, Google Vertex AI oder jeden anderen OpenAI-kompatiblen Modell-Service nutzen. Das Bob-Backend, Identity, Audit-Logs und Metering verbleiben auf dem Cluster. Modellanfragen samt dem übergebenen Code-Kontext gehen über die bereits bestehenden Vereinbarungen an das eigene Cloud-Konto des Unternehmens. Dieser Weg eignet sich für Organisationen, die bereits über freigegebenen Zugriff auf einen Cloud-Modell-Service verfügen, aber alles Weitere unter eigener Kontrolle behalten müssen.

Vollständig selbst gehostet. Für Netzwerke ohne ausgehende Verbindung läuft das Modell auf den eigenen GPUs der Organisation. Zwei Open-Weight-Modelle werden für diesen Pfad unterstützt: NVIDIA Nemotron 3 Ultra und Poolside Laguna S 2.1. Bobs Agent-Harness wurde für jedes dieser Modelle optimiert und evaluiert. Das Hardware-Sizing richtet sich nach den Vorgaben der jeweiligen Hersteller, da es von Quantisierung, Kontextlänge und der Anzahl gleichzeitig bedienter Entwickler abhängt. Ein kleines Guardrail-Modell prüft Ein- und Ausgaben auf diesem Pfad, und Bob IDE sowie Bob Shell binden es nach der Konfiguration automatisch ein.

Eine zweistufige Installation

Die Installation wird über bobctl abgewickelt, Bobs Installations-CLI für Self-Hosted-Deployments, und erfolgt in zwei Stufen. Die erste erstellt die clusterweiten Komponenten: Ressourcendefinitionen, Berechtigungen und den Operator. Sie erfordert Cluster-Admin-Rechte und durchläuft in den meisten Unternehmen das Change-Review des Plattform-Teams. Die zweite Stufe installiert Bob selbst in einen Namespace und benötigt lediglich Zugriff auf Namespace-Ebene.

Durch diese Trennung prüft und genehmigt das Plattform-Team den clusterweiten Footprint einmalig. Danach kann das Team, das Bob betreibt, das System installieren, aktualisieren und neu konfigurieren, ohne Cluster-Admin-Rechte zu besitzen oder für jede Änderung ein Ticket zu eröffnen.

Vollständig isolierte Air-Gapped-Cluster sind ein unterstützter Installationspfad. bobctl spiegelt die Bob-Images in eine private Registry – auch für den Fall, dass Images auf einem verbundenen Rechner heruntergeladen, über die physische Trennung hinweg übertragen und von der isolierten Seite aus gepusht werden.

Eine Single-Node-OpenShift-Installation reicht für ein Proof of Concept aus. Produktions-Sizing und Voraussetzungen werden in der Installationsdokumentation behandelt.

Identitätsverwaltung über das Unternehmensverzeichnis

Ein Self-Hosted-Deployment enthält einen eigenen Identity-Service auf Basis von Keycloak, der an das LDAP oder Active Directory des Unternehmens angebunden werden kann. Nach der Anbindung melden sich Entwickler mit ihren Unternehmens-Anmeldedaten an, und der Zugriff folgt dem Verzeichnis: Hinzugefügte Personen werden in Bob bereitgestellt, und entfernte Personen verlieren den Zugriff automatisch. Kleinere Installationen und Proofs of Concept können Benutzer stattdessen direkt im Identity-Service verwalten.

So erhältst du Self-Hosted Bob

Das Self-Hosted-Deployment wird über den Vertrieb vertrieben. Um eine Demo zu sehen oder ein Proof of Concept zu starten, wende dich an einen IBM-Ansprechpartner oder Business Partner, oder nutze „Contact Sales“ auf bob.ibm.com. Das Account-Team richtet die Berechtigung für die Organisation ein, einschließlich aller Premium-Pakete.

Starte mit einem Single-Node-OpenShift-Proof-of-Concept, das auf einen bereits vom Unternehmen betriebenen Modell-Endpunkt verweist, und verbinde die Bob IDE eines Teams damit. Die Dokumentation zum Self-Hosted-Deployment beschreibt den Weg von dort bis zum Produktivbetrieb, einschließlich Air-Gapped-Installation, Backup und Restore.

Mehr in dieser Monatsveröffentlichung

MCP-Client auf v2 aktualisiert

Der MCP-Client unterstützt jetzt die Spezifikation MCP 2026-07-28 einschließlich des zustandslosen Streamable-HTTP-Transports, behält jedoch die Kompatibilität mit MCP 2025 Streamable HTTP- und stdio-Servern bei. Die Abwicklung des OAuth-Protokolls wandert in den Client.

Breaking Change: Die Unterstützung für den HTTP+SSE-Transport wurde entfernt, und Bob lehnt HTTP+SSE-Konfigurationen beim Start ab. MCP-Server, die noch HTTP+SSE verwenden, müssen vor dem Upgrade von Bob auf Streamable HTTP umgestellt werden.

Für Administratoren

Gruppenrichtlinie RequiredExtensions. Die Gruppenrichtlinie zur Verteilung des Self-Hosted-Endpunkts kann nun auch VS-Code-Extensions installieren. Admins tragen Extension-IDs in die neue Richtlinie RequiredExtensions ein, und Bob installiert diese beim Start über den Marketplace – ganz ohne Zutun der Entwickler. Die Richtlinie nutzt dieselben ADMX/ADML-Vorlagen, Mobile-Device-Management- und Richtliniendatei-Mechanismen, die bereits Bobs eigene Einstellungen steuern.

Plugin-Verzeichnisse. Skills, Modes, Rules-Dateien und MCP-Konfigurationen können jetzt auf Workspace-Ebene unter .bob/plugins/<plugin-name>/ oder global unter ~/.bob/plugins/<plugin-name>/ abgelegt werden und werden von Bob beim Start geladen. Ein Team kann einen benutzerdefinierten Mode, die referenzierten Rules, aufgerufenen Skills und eine MCP-Konfiguration zusammen als ein Plugin-Verzeichnis bereitstellen. Das bestehende Layout auf Root-Ebene funktioniert weiterhin.

Für Entwickler

Hintergrundprozesse. Builds, Watcher, Dev-Server und andere langlebige Befehle starten jetzt im Hintergrund, statt die Konversation zu blockieren. Eine Anzeige im Chat-View zeigt an, was gerade läuft; klicke darauf, um die Ausgabe einzusehen oder den Prozess zu stoppen.

Webseiten abrufen (experimentell). Bob kann eine Dokumentationsseite, eine API-Referenz oder eine andere bekannte URL abrufen und als Markdown oder Plain Text lesen. Aktiviere dafür zuerst web_fetch in Settings → Chat.

Compaction-Lifecycle-Hooks. PreCompact wird vor der Kontext-Kompaktierung ausgeführt und kann diese blockieren; PostCompact läuft nach Abschluss der Kompaktierung. /compress in der Chat-Eingabe stößt die Kompaktierung manuell an.

Konfigurierbare Chat-Breite. Settings → Chat → Appearance bietet Default, Wide und Full width, und die Auswahl bleibt sitzungsübergreifend erhalten.

Außerdem in dieser Version

Hook-Events können an HTTPS-Endpunkte gesendet werden. HTTP-Hook-Handler sind jetzt in der Bob Settings UI konfigurierbar.
watsonx Governance ist jetzt im Bob Marketplace verfügbar.
Follow-up-Fragen erscheinen jetzt einzeln nacheinander statt gesammelt im Batch.
MCP-Servernamen bleiben in Tool-IDs erhalten, was die Zuordnung erleichtert, von welchem Server ein bestimmter Tool-Aufruf stammt.
Dateiüberwachung (File Watching) und Skill-Erkennung funktionieren jetzt in Remote-SSH-Workspaces.
Ungültige Skill-Verzeichnisnamen führen beim Start zu einer Warnung.

Probiere die neueste Version aus

Stelle vor dem Upgrade alle MCP-Server, die noch auf HTTP+SSE laufen, auf Streamable HTTP um. Starte dann einen Dev-Server in einer Session und arbeite einfach weiter, während er im Hintergrund läuft.

Um ein Team-Setup zu teilen, lege einen benutzerdefinierten Mode, die referenzierten Rules und die aufgerufenen Skills unter .bob/plugins/<plugin-name>/ ab und committe das Verzeichnis ins Repository. Bob lädt das Plugin beim Start für jeden, der den Workspace öffnet. Richte Bob bei aktiviertem web_fetch auf die API-Referenz einer Bibliothek aus, bevor du ihn bittest, Code für diese Bibliothek zu schreiben.