El despliegue autoalojado lidera el lanzamiento de este mes

A partir del 24 de septiembre de 2026, IBM Bob está disponible de forma general para despliegues autoalojados. El backend de Bob se ejecuta en clústeres de Red Hat OpenShift que la propia organización opera, on-premises o en su propia cuenta de nube. El modelo es un modelo frontera de un servicio de modelos en la nube que la organización ya utiliza, o bien un modelo open-weight en sus propias GPU. Los desarrolladores continúan utilizando el mismo Bob IDE y Bob Shell que ya conocen. El lanzamiento de este mes también añade procesos en segundo plano, un cliente MCP actualizado y nuevos controles para administradores.

El servicio en la nube de Bob sigue siendo la opción predeterminada adecuada para la mayoría de los equipos de ingeniería: sin infraestructura que gestionar, actualizaciones que llegan automáticamente y un backend operado por quienes lo crearon. Para muchas grandes organizaciones de ingeniería esa opción predeterminada no es viable, ya que su código fuente no puede salir de la infraestructura bajo su control. Bajo las reglas de residencia de datos, Bob puede utilizar un modelo frontera mediante la propia cuenta de nube de la organización. En una red aislada (air-gapped), Bob utiliza un modelo open-weight en las propias GPU de la organización.

Despliegue autoalojado

Qué incluye un despliegue autoalojado

El despliegue autoalojado empaqueta el backend de Bob para Red Hat OpenShift. Incluye identidad, la pasarela de inferencia (inference gateway), registro de auditoría y medición de uso, todo gestionado por un operador que se encarga de la instalación, las actualizaciones y las operaciones de día 2. Bob se ejecuta como una carga de trabajo ordinaria con espacio de nombres (namespaced), por lo que puede compartir un clúster existente con otras aplicaciones.

Los desarrolladores siguen trabajando en Bob IDE y Bob Shell como antes. El endpoint autoalojado se distribuye habitualmente mediante directivas de grupo (group policy), de modo que los clientes se conectan al clúster interno sin necesidad de configuración alguna por parte del desarrollador. El harness del agente detrás de él es el mismo que se ejecuta contra el servicio en la nube.

Los paquetes premium también funcionan en un despliegue autoalojado: IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i e IBM Bob Premium Package for Z (PP4Z). Un administrador de Bob los asigna a los usuarios en la misma interfaz de administración (Admin UI) que en el servicio en la nube. PP4Z incluye componentes de backend propios, como Z Understand, y el administrador del clúster decide en el momento de la instalación si desplegarlos.

Dos formas de conectar un modelo

Bob autoalojado se conecta a un modelo de una de dos formas.

Modelos frontera mediante la cuenta de nube de la organización. Bob puede utilizar modelos frontera a través de AWS Bedrock, Azure OpenAI, Google Vertex AI o cualquier otro servicio de modelos compatible con OpenAI. El backend de Bob, la identidad, los registros de auditoría y la medición permanecen en el clúster. Las solicitudes al modelo, incluido el contexto de código que transportan, se dirigen a la propia cuenta de nube de la organización conforme a los acuerdos que ya tiene establecidos. Esta vía se adapta a las organizaciones que ya cuentan con acceso aprobado a un servicio de modelos en la nube pero necesitan mantener todo lo demás bajo su propio control.

Totalmente autoalojado. Para redes sin conexión saliente, el modelo se ejecuta en las propias GPU de la organización. Se admiten dos modelos open-weight para esta vía: NVIDIA Nemotron 3 Ultra y Poolside Laguna S 2.1. El harness del agente de Bob fue ajustado y evaluado con cada uno de ellos. El dimensionamiento del hardware sigue las directrices de cada proveedor, ya que depende de la cuantización, la longitud de contexto y la cantidad de desarrolladores atendidos simultáneamente. Un modelo de guardrail pequeño filtra las entradas y salidas en esta vía, y Bob IDE y Bob Shell lo incorporan automáticamente una vez configurado.

Una instalación en dos etapas

La instalación es gestionada por bobctl, la CLI de instalación de Bob para despliegues autoalojados, y se ejecuta en dos etapas. La primera crea los componentes a nivel de todo el clúster: definiciones de recursos, permisos y el operador. Requiere privilegios de cluster-admin y, en la mayoría de las empresas, pasa por la revisión de cambios del equipo de plataforma. La segunda etapa instala Bob propiamente en un namespace y solo necesita acceso a nivel de namespace.

Esta división permite que el equipo de plataforma revise y apruebe la huella a nivel de clúster una sola vez. A partir de ahí, el equipo propietario de Bob puede instalarlo, actualizarlo y reconfigurarlo sin necesidad de disponer de permisos de cluster-admin ni de abrir un ticket para cada cambio.

Los clústeres totalmente aislados (air-gapped) son una vía de instalación soportada. bobctl replica las imágenes de Bob en un registro privado, incluido el caso en que las imágenes se descargan en una máquina conectada, se transfieren a través del aislamiento físico y se suben desde el lado aislado.

Una instalación de OpenShift de un solo nodo es suficiente para una prueba de concepto. El dimensionamiento para producción y los requisitos previos se detallan en la documentación de instalación.

Identidad mediante el directorio corporativo

Un despliegue autoalojado incluye su propio servicio de identidad, basado en Keycloak, que se puede conectar al LDAP o Active Directory de la organización. Una vez conectado, los desarrolladores inician sesión con sus credenciales corporativas y el acceso sigue al directorio: los usuarios añadidos a él se aprovisionan en Bob y los eliminados pierden el acceso automáticamente. Las instalaciones más pequeñas y las pruebas de concepto pueden gestionar los usuarios directamente en el servicio de identidad.

Cómo obtener Bob autoalojado

El despliegue autoalojado se gestiona a través del equipo de ventas. Para ver una demo o iniciar una prueba de concepto, ponte en contacto con un representante de IBM o Business Partner, o utiliza Contact Sales en bob.ibm.com. El equipo de cuenta configura la titularidad para la organización, incluidos los paquetes premium.

Comienza con una prueba de concepto de OpenShift de un solo nodo apuntando a un endpoint de modelo que la organización ya opere y conecta el Bob IDE de un equipo a él. La documentación de despliegue autoalojado cubre el camino desde allí hasta la producción, incluyendo la instalación air-gapped, copias de seguridad y restauración.

Más novedades en el lanzamiento de este mes

Cliente MCP actualizado a v2

El cliente MCP ahora soporta la especificación MCP 2026-07-28, incluyendo el transporte Streamable HTTP sin estado (stateless), manteniendo la compatibilidad con servidores MCP 2025 Streamable HTTP y stdio. La gestión del protocolo OAuth pasa al cliente.

Cambio disruptivo: Se ha eliminado el soporte para el transporte HTTP+SSE, y Bob rechaza las configuraciones HTTP+SSE al iniciarse. Los servidores MCP que aún utilicen HTTP+SSE deben actualizarse a Streamable HTTP antes de actualizar Bob.

Para administradores

Directiva de grupo RequiredExtensions. La directiva de grupo que distribuye el endpoint autoalojado ahora también puede instalar extensiones de VS Code. Los administradores listan los IDs de las extensiones en la nueva directiva RequiredExtensions, y Bob las instala desde el marketplace al iniciar, sin que el desarrollador tenga que intervenir. La directiva utiliza las mismas plantillas ADMX/ADML, gestión de dispositivos móviles (MDM) y mecanismos de archivos de directivas que ya rigen la configuración propia de Bob.

Directorios de plugins. Los skills, modos, archivos de reglas y configuraciones MCP ahora se pueden ubicar bajo .bob/plugins/<plugin-name>/ a nivel de espacio de trabajo, o ~/.bob/plugins/<plugin-name>/ a nivel global, y Bob los detecta al iniciar. Un equipo puede distribuir un modo personalizado, las reglas que referencia, los skills que invoca y una configuración MCP juntos en un único directorio de plugin. La estructura existente en el nivel raíz sigue funcionando.

Para desarrolladores

Procesos en segundo plano. Las compilaciones, watchers, servidores de desarrollo y otros comandos de larga duración ahora se inician en segundo plano en lugar de bloquear la conversación. Un indicador en la vista de chat muestra lo que se está ejecutando; haz clic en él para inspeccionar la salida o detener el proceso.

Obtención de páginas web (experimental). Bob puede obtener una página de documentación, una referencia de API u otra URL conocida y leerla como Markdown o texto plano. Habilita primero web_fetch en Settings → Chat.

Hooks del ciclo de vida de compactación. PreCompact se ejecuta antes de la compactación de contexto y puede bloquearla; PostCompact se ejecuta después de que finalice. /compress en la entrada de chat activa la compactación manualmente.

Ancho de chat configurable. Settings → Chat → Appearance ofrece ancho Default, Wide y Full, y la elección se mantiene entre sesiones.

También en este lanzamiento

Los eventos de hooks se pueden enviar a endpoints HTTPS. Los manejadores de hooks HTTP ahora son configurables en la interfaz de configuración de Bob (Bob Settings UI).
watsonx Governance ya está disponible en Bob Marketplace.
Las preguntas de seguimiento ahora aparecen una por una en lugar de en lote.
Los nombres de los servidores MCP se conservan en los IDs de herramientas, lo que facilita rastrear de qué servidor proviene una llamada a una herramienta determinada.
La observación de archivos (file watching) y el descubrimiento de skills ahora funcionan en espacios de trabajo Remote SSH.
Los nombres de directorio de skills no válidos muestran una advertencia al iniciar.

Prueba el último lanzamiento

Antes de actualizar, migra cualquier servidor MCP que aún use HTTP+SSE a Streamable HTTP. Luego inicia un servidor de desarrollo en una sesión y continúa trabajando mientras se ejecuta en segundo plano.

Para compartir una configuración de equipo, coloca un modo personalizado, las reglas que referencia y los skills que invoca bajo .bob/plugins/<plugin-name>/ y haz commit del directorio en el repositorio. Bob detectará el plugin al iniciar para cualquiera que abra el espacio de trabajo. Con web_fetch habilitado, apunta Bob a la referencia de API de una librería antes de pedirle que escriba código para esa librería.