BullSequana hardware
Prepare an on-premises BullSequana environment for CLI and GitOps deployment.
BullSequana hardware is the reference self-managed deployment model. Render the desired state with the platform CLI and reconcile it through Argo CD.
Prepare the cluster foundation
Provide a Kubernetes cluster with the required CPU, memory, GPU, and storage capacity. Install compatible NVIDIA drivers and the container runtime on GPU nodes, then use the cluster owner's supported device-plugin integration or run bsqai helm-apply gpu-operator. Define the labels, taints, and quotas used by the site's KServe profiles. See Enable GPU for AI components for the exact boundary.
For bare-metal external access, provide a load-balancer implementation that assigns a stable address to Envoy Gateway. Route platform hostnames to that address and ensure firewalls allow the required HTTPS and operator traffic.
Storage decisions
Rook-Ceph can provide block, shared-file, and S3-compatible storage when the cluster supplies suitable raw devices and failure-domain labels. Confirm the disk inventory, Ceph replication policy, and recovery ownership before enabling it.
Sites with an existing S3-compatible service can use external-s3. The storage operator supplies reachable private and public endpoints, trusted CA material, credentials, buckets, and provider capabilities through one approved handoff. The BullSequana AI deployment operator maps them into the protected site configuration. A separate shared model store is optional.
Set the real RWO and RWX storage classes in the common platform configuration.
Private registry and disconnected delivery
Mirror every release image and Helm chart into the approved registry. Set the platform registry repositories and pull credentials. For a registry signed by private PKI, set COMMON_REGISTRY_CERTIFICATE to the base64-encoded CA PEM so Argo CD can pull OCI charts.
Use COMMON_DOCKER_CONFIG_JSON when workloads also need other private registries.
DNS and certificates
BullSequana AI uses Gateway API through Envoy Gateway. Provide wildcard DNS and a certificate strategy for the base domain. DNS may be managed automatically when the site's provider is supported, or manually by the infrastructure team.
For private PKI, provide the CA and wildcard certificate through [custom_tls] and distribute the trust chain to clients that access the platform.
Cluster DNS and proxies
Set the internal resolver name, namespace, and cluster domain when they differ from Kubernetes defaults. In restricted networks, configure HTTP, HTTPS, and no-proxy values so in-cluster service names, the API server, Git, registry, and object-storage endpoints bypass the proxy where required.
Validate before bootstrap
bsqai test-k8s
bsqai validate
bsqai load
bsqai apply all -rInspect generated storage, Gateway, CA, registry, and scheduling values before pushing the GitOps state.