System requirements
Before an on-premises installation of Bob, ensure that your environment meets the supported platform, architecture, compute, storage, and networking requirements.
Provisional sizing values for Z Understand add-on configurations are now published. These values are based on benchmark testing in progress and may be updated as testing is completed.
The requirements in this section help you plan and size your OpenShift environment appropriately.
Supported versions
The following table lists the Bob on-premises versions and the compatible client component versions.
| Bob on-premises version | Bob IDE version | Bob Shell version |
|---|---|---|
| 2.0.0 | 2.2.0 | 2.0.5 |
For Premium Package add-on version compatibility, see Managing entitlements.
Cluster architecture
An on-premises installation of Bob on OpenShift Container Platform (OCP) currently supports the following cluster architecture:
amd64(x86_64)
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 | Notes |
|---|---|---|
| 4.20 | Tested and supported | Minimum supported version |
| 4.21 | Tested and supported | |
| 4.22 | Tested and supported |
Cluster sizing
Bob runs as a tenant workload on a customer-managed OpenShift cluster. Resource requirements vary based on the deployed Bob stack. Every installation includes the Bob core components, while optional Premium Package add-ons increase the required CPU, memory, and storage capacity.
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.
Cluster sizing decisions such as the number of control plane nodes, infrastructure nodes, worker nodes, high-availability requirements, and growth planning remain your responsibility.
Supported stack configurations
Bob supports multiple deployment configurations. The total resource footprint depends on the enabled add-ons.
| Stack configuration | CPU (raw) | Memory (raw) | Storage (PVs) | Status |
|---|---|---|---|---|
| Bob Core | 38.1 vCPU | 42.1 GiB | ~50 GiB | Baseline available |
| Bob Core + RAG | 38.1 vCPU | 69.1 GiB | ~62 GiB | Baseline available |
| Bob Core + Z Understand | 30.1 vCPU | 79.1 GiB | ~2288 GiB | Benchmarking in progress |
| Bob Core + RAG + Z Understand | 46.1 vCPU | 113.1 GiB | ~2320 GiB | Benchmarking in progress |
Bob Core represents the minimum supported deployment configuration. Resource values represent aggregate Bob tenant requirements and exclude platform infrastructure overhead. Add-on resource requirements will be published upon completion of performance testing.
Bob resource footprint
The following reference footprint applies to a Bob Core deployment with no optional add-ons enabled.
| Deployment profile | CPU | Memory | Storage (PVs) |
|---|---|---|---|
| Evaluation (raw) | 16.8 vCPU | 20.8 GiB | ~9 GiB |
| Evaluation (+25–30% headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Production (raw) | 28.1 vCPU | 41.1 GiB | ~50 GiB |
| Production (+25–30% headroom) | ~36.5 vCPU | ~53.4 GiB | ~50 GiB |
The recommended values include scheduling headroom to accommodate platform overhead, workload fluctuations, upgrades, and future growth. Use the headroom-adjusted values when sizing worker node capacity.
Single node OpenShift (SNO) cluster
Single node OpenShift combines the control plane and worker workloads on a single host. SNO deployments are suitable for proof-of-concept, development, testing, and edge environments where high availability is not required.
Reference sizing
| Layer | CPU | Memory | Storage |
|---|---|---|---|
| OpenShift platform minimum | 8 vCPU | 16 GiB | 120 GiB |
| Bob evaluation workload (with headroom) | ~21 vCPU | ~26 GiB | ~9 GiB |
| Total node reference | ~29 vCPU | ~42 GiB | ~130 GiB |
- Single node OpenShift does not provide node redundancy.
- Control plane and application workloads share the same host.
- A node failure results in complete service unavailability.
- SNO is not recommended for production environments that require availability or disaster recovery capabilities.
For installation guidance, see How to install single node OpenShift on bare metal (minimum 8 vCPU / 16 GiB RAM / 120 GiB storage) and Preparing to install on a single node, OCP 4.20.
Multi-node OpenShift cluster
The following architecture represents a minimum reference deployment for Bob running in a dedicated cluster.
Minimum reference configuration
| Node role | Count | CPU per node | Memory per node | Aggregate resources |
|---|---|---|---|---|
| Control plane | 3 | 4 vCPU | 16 GiB | 12 vCPU / 48 GiB |
| Infrastructure | 3 | ~4 vCPU | ~16 GiB | 12 vCPU / 48 GiB |
| Worker | 3 | 20 vCPU | 24 GiB | 60 vCPU / 72 GiB / 600 GiB storage |
| Cluster total | 9 | - | - | ~84 vCPU / ~168 GiB / 600 GiB |
After accounting for OpenShift overhead, the worker node pool provides approximately:
- 57 vCPU allocatable capacity
- 63 GiB allocatable memory
This capacity is sufficient to support the Bob Core production footprint, including recommended scheduling headroom:
| Requirement | CPU | Memory |
|---|---|---|
| Bob Core production requirement | ~36.5 vCPU | ~53.4 GiB |
| Worker pool allocatable capacity | ~57 vCPU | ~63 GiB |
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 | Status |
|---|---|---|---|
| Managed NFS | Network File System (NFS) provisioner | RWO, RWX | Supported |
| OpenShift Data Foundation (ODF) | Ceph-backed storage (RBD and CephFS) | RWO, RWX | Supported |
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 on-premises 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.