System requirements
Before a self-hosted installation of Bob, ensure that your environment meets the supported platform, architecture, compute, storage, and networking requirements.
The requirements in this section help you plan and size your OpenShift environment appropriately.
Supported versions
The following table lists the validated component versions supported for this release of Bob self-hosted. Ensure that your deployment uses supported versions of Bob IDE, Bob Shell, Premium Package, and OpenShift Container Platform (OCP) to maintain compatibility and receive full product support.
| Bob self-hosted version | Bob IDE version | Bob Shell version | Premium Package version |
|---|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 | IBM Bob Premium Package for Z 3.1.0 |
Cluster architecture
The Bob on-premises backend requires an amd64 (x86_64) OCP cluster. All worker nodes that schedule Bob workloads must run on amd64 hardware.
| Architecture | Backend cluster support |
|---|---|
amd64 (x86_64) | Supported |
Mixed-architecture clusters are supported when Bob workloads are restricted to amd64 nodes by using node selectors or taints. Bob does not apply these scheduling constraints automatically.
Supported OCP versions
The following table lists the supported OCP versions.
| OCP version | Status |
|---|---|
| 4.20 | Supported |
| 4.21 | Supported |
| 4.22 | Supported |
Deployment footprint and sizing
Bob self-hosted is deployed as a tenant workload on a customer-managed OpenShift Container Platform (OCP) cluster. Resource requirements vary based on the Bob components that you deploy and are not fixed for all installations.
Every deployment includes Bob Core, which provides the foundational platform services. Optional components, such as Z Context tool, Z Proxy, and Z Understand, require additional compute, memory, and storage resources and must be considered when sizing the cluster.
Add-ons are enabled during installation by the cluster administrator. Enabling an add-on not only increases cluster resource requirements but also determines whether the corresponding premium package entitlement can be assigned to users. For more information, see Managing entitlements.
The sizing values in this section represent the aggregate resources required by Bob workloads. They are provided to help estimate the tenant footprint and are not intended to define the overall cluster architecture. You must size the underlying cluster based on your operational requirements, including high availability, other tenant workloads, expected growth, and platform service overhead.
These figures represent the sum of configured pod resource requests across all Bob components at their specified replica counts. This is the amount of CPU and memory that the Kubernetes scheduler reserves on cluster nodes.
These values are intended for capacity planning and sizing purposes only. They do not represent observed runtime resource usage and should not be interpreted as guaranteed resource consumption under load.
Cluster sizing decisions such as the number of control plane nodes, infrastructure nodes, worker nodes, high-availability requirements, and growth planning remain your responsibility.
Model serving (inference) is not included. The resource estimates in this section do not include GPU nodes, model-serving infrastructure, or other resources required to host and serve AI models. If you run model inference using Red Hat OpenShift AI or a separate model-serving platform, plan and size those environments independently from the Bob deployment.
Supported stack configurations
Review the configuration that most closely matches your planned deployment when sizing your OpenShift cluster.
| Stack configuration | CPU (raw) | Memory (raw) | Storage (PVs) |
|---|---|---|---|
| Bob Core | 10.8 vCPU | 10.8 GiB | ~24 GiB |
| Bob Core + Z Context tool | 27.8 vCPU | 45.8 GiB | ~55 GiB |
| Bob Core + Z Understand | 18.8 vCPU | 49.8 GiB | ~24 GiB |
| Bob Core + Z Context tool + Z Understand | 35.8 vCPU | 84.8 GiB | ~55 GiB |
Bob Core represents the minimum supported deployment configuration. Resource values represent aggregate Bob tenant requirements and exclude platform infrastructure overhead.
Bob resource footprint
The following reference footprint applies to a Bob Core deployment with no optional add-ons enabled.
When sizing worker nodes, use the values in the +25% scheduling headroom row. These values provide additional capacity beyond the configured pod resource requests to account for Kubernetes scheduling requirements and node-level overhead.
| Deployment profile | CPU | Memory | Storage (PVs) |
|---|---|---|---|
| Production (requested resources) | 10.8 vCPU | 10.8 GiB | ~24 GiB |
| Production (including 25% scheduling headroom) | ~13.5 vCPU | ~13.5 GiB | ~24 GiB |
Storage consumption varies based on workload volume, retained data, and enabled services. The values shown represent the baseline footprint for a Bob Core deployment.
OpenShift cluster topology
The following table shows a minimum production-capable reference configuration for a nine-node OpenShift cluster running a Bob Core deployment. If you deploy additional Bob components, you must provision additional worker node capacity.
Minimum reference configuration
| Node role | Count | CPU per node | Memory per node | Aggregate capacity |
|---|---|---|---|---|
| Control plane | 3 | 4 vCPU (minimum) | 16 GiB (minimum) | 12 vCPU / 48 GiB |
| Infrastructure nodes | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker nodes | 3 | 8 vCPU | 16 GiB | 24 vCPU / 48 GiB / 600 GiB storage |
| Total cluster | 9 | - | - | ~48 vCPU / ~144 GiB / 600 GiB storage |
After accounting for OpenShift cluster overhead and system-reserved resources, the three-worker-node configuration provides sufficient allocatable CPU and memory capacity to support the Bob Core production deployment.
For reference, see OpenShift Control Plane Sizing Guidelines, Control plane node sizing (keep utilization at 60% or below for HA and upgrade headroom), and Recommended host practices, Scalability and Performance (3 infra nodes recommended).
Storage requirements
Bob relies on persistent storage for databases, search services, cache components, configuration, certificates, and backup data. Selecting the appropriate storage class is important for performance and reliability.
The reference configuration allocates 200 GiB of storage per worker node, for a total of 600 GiB across the worker pool. This accommodates Bob persistent volume requirements (~50 GiB), OpenShift internal services such as image registry, monitoring, and logging, and capacity for future workload growth.
Supported storage classes
| Storage class | Type | Supported access modes |
|---|---|---|
| Managed NFS | Network File System (NFS) provisioner | RWO, RWX |
| OpenShift Data Foundation (ODF) | Ceph-backed storage (RBD and CephFS) | RWO, RWX |
Storage access mode requirements
Different Bob components require different storage access modes.
| Component | Required access mode | Notes |
|---|---|---|
| PostgreSQL | RWO (ReadWriteOnce) | Block storage is required. SSD-backed storage is strongly recommended. |
| OpenSearch | RWO (ReadWriteOnce) | High-performance block storage is recommended. |
| Redis | RWO (ReadWriteOnce) | Persistent data requires dedicated read-write access. |
| Shared configuration and certificates | RWX (ReadWriteMany) | Required when multiple pods must mount the same volume concurrently. |
Storage performance has a significant impact on Bob self-hosted responsiveness and stability.
Insufficient storage throughput or I/O performance, particularly for PostgreSQL workloads, can result in increased response times, slower indexing operations, and degraded overall system performance. When selecting storage for database workloads:
- Use SSD-backed block storage whenever possible.
- Avoid storage platforms with high latency or limited IOPS.
- Ensure sufficient capacity for expected workload growth.
- Validate storage performance before deploying production workloads.
For optimal performance, deploy PostgreSQL and OpenSearch data volumes on the fastest available block storage in the environment.
Backup storage
Bob requires a separate storage target for backup and restore operations. The backup storage location must provide sufficient capacity to store:
- Application backups
- Database backups
- Index snapshots
- Retention copies required by organizational policies
Backup storage can be provided by supported external storage systems, such as:
- Network File System (NFS) shares
- Enterprise backup repositories
- Object storage services (if supported by the backup solution)
Network requirements
Bob components communicate internally within the OpenShift cluster and externally with model endpoints, container registries, LDAP providers, and client workstations. Before installation, verify that the required network connectivity and DNS configuration are available.
At a minimum, ensure that:
- OpenShift nodes can communicate with each other.
- Your workstation can access the OpenShift API.
- Bob can reach configured LLM endpoints.
- Bob can reach LDAP or Active Directory servers, if used.
- Client workstations can access the Bob ingress endpoint.
- DNS records are configured for the Bob application endpoint.
- TLS certificates can be validated from client workstations.