# BullSequana Hardware (/docs/deployment/environments/bullsequana-hardware) This page gives a practical default configuration shape for `BullSequana hardware` and similar on-premises environments. It is based on the current `coreai-platform/deployments/terraform/bsq-ai` Terraform layer, but shaped for a deployment where: * the cluster is on customer-controlled or BullSequana-delivered infrastructure * DNS is managed according to the local infrastructure ownership model * TLS material is provided directly through the deployment inputs * registry access points to an internal or customer-controlled container registry * images and Helm artifacts are mirrored into local registry paths for controlled delivery When This Page Applies [#when-this-page-applies] Use this page when BullSequana AI is deployed on: * BullSequana hardware delivered as the primary platform footprint * customer-owned on-premises Kubernetes infrastructure * private-cloud environments that behave operationally like on-premises delivery This is the reference environment for the platform. Practical On-Prem Baseline [#practical-on-prem-baseline] The `secrets.auto.tfvars.example` comments already suggest a sensible on-prem storage baseline: * `rwo_storageclass = "local-path"` * `rwx_storageclass = "nfs-client"` That is the best starting point for a default documentation example because: * it matches the codebase guidance * it avoids cloud-specific provider assumptions in the baseline * it fits the typical split between local persistent storage and shared RWX storage Air-Gapped BullSequana Pattern [#air-gapped-bullsequana-pattern] A real BullSequana hardware deployment in an air-gapped or tightly controlled environment often looks more specific than the generic on-prem baseline. Common characteristics are: * `rwo_storageclass = "openebs-local"` * `rwx_storageclass = "nfs-client"` * `internal_resolver = "coredns"` * `custom_tls.enabled = true` * internal Git access over `SSH` * mirrored registry repository prefixes under a local project path * explicit proxy fields, even if they are intentionally empty in a fully disconnected environment That still follows the same BullSequana AI deployment model. It is simply a stricter local-delivery variant of it. Minimal BullSequana Hardware Example [#minimal-bullsequana-hardware-example] ```hcl common_config = { ingressclassname = "nginx" imagepullsecret = "registry-secret" base_domain = "." wildcard_cert_secret_name = "wildcard-tls" rwo_storageclass = "openebs-local" rwx_storageclass = "nfs-client" realm_name = "dataplatform" registry = "" registry_platform_repository = "/coreai/platform" registry_backend_repository = "/coreai/backend" registry_portal_repository = "/coreai/portal" registry_helm_repository = "/coreai/helm" http_proxy_url = "" https_proxy_url = "" no_proxy_url = "" coreai_components = true proai_components = true enforce_affinity = false internal_resolver = "coredns" } git_config = { git_repo_url = "ssh://@/.git" git_branch = "" git_path = "data-platform" } dockerconfigjson = "" custom_tls = { enabled = true ca_crt = "" tls_crt = "" tls_key = "" } ``` What This Baseline Assumes [#what-this-baseline-assumes] This baseline assumes a few explicit operational choices. DNS is handled through the local infrastructure model [#dns-is-handled-through-the-local-infrastructure-model] This baseline assumes DNS records are created and managed according to the local infrastructure operating model rather than through cloud-specific variables in the deployment input. TLS is provided directly [#tls-is-provided-directly] The safest default on-prem posture is: * `custom_tls.enabled = true` * provide the wildcard certificate and key directly * optionally provide the CA bundle when required by the environment This aligns better with private PKI, customer-owned certificate issuance, or enterprise-managed certificate workflows. Registry is internal or customer-controlled [#registry-is-internal-or-customer-controlled] On BullSequana hardware and similar on-prem environments, the registry path is often: * an internal Harbor registry * a customer-operated registry service * a mirrored registry prepared during factory or delivery staging That is why the example uses: ```hcl registry = "" ``` while keeping the same platform repository structure under local mirrored prefixes: * `/coreai/platform` * `/coreai/backend` * `/coreai/portal` * `/coreai/helm` The exact prefix can vary by customer or delivery model. The important point is consistency between the local Harbor project structure, the deployment inputs, and the image references used by the manifests. Git is local too [#git-is-local-too] In air-gapped or tightly controlled BullSequana environments, the Git source is often internal as well. That usually means: * an internal `GitLab` instance * an `SSH` repository URL rather than a public HTTPS path * a customer- or environment-specific branch for the manifests This keeps the desired-state source local in the same way Harbor keeps the runtime artifacts local. Proxy fields should be explicit [#proxy-fields-should-be-explicit] The Terraform input model supports: * `http_proxy_url` * `https_proxy_url` * `no_proxy_url` For a fully disconnected environment, these may intentionally stay empty. For a restricted but connected environment, they should be filled explicitly rather than left ambiguous. Storage Guidance [#storage-guidance] The current example comments in the Terraform repo already highlight the main storage concern: * some components need `ReadWriteMany` * `Docling` and shared document/model workflows benefit from RWX support That is why the baseline keeps: * `openebs-local` or another local persistent CSI for `RWO` * `nfs-client` for `RWX` If your on-prem environment uses different storage integrations, replace those names with the actual classes exposed by the cluster. Examples might include: * `rook-ceph-block` and `rook-cephfs` * `longhorn` for both paths in smaller environments * another customer-standard CSI and shared-storage pair Important Current Constraint: `external-dns` [#important-current-constraint-external-dns] One code-level constraint should be called out explicitly. In the current `coreai-platform` deployment layer: * `components_config.external_dns.enabled` defaults to `true` * the rendered `external-dns` values assume a provider-specific DNS automation path So a real on-prem deployment should not assume that the current out-of-the-box `external-dns` settings are correct. Operationally, that means one of these must be true: 1. DNS records are managed outside the current Terraform layer. 2. The deployment layer is adapted for the real on-prem DNS provider. 3. The component configuration is overridden so the default provider-specific `external-dns` path is not used. This is exactly why the BullSequana hardware baseline on this page keeps DNS ownership and TLS decisions explicit instead of relying on cloud-specific inputs. Recommended Operating Model [#recommended-operating-model] For a practical `BullSequana Hardware` baseline, start with this model: 1. Use internal or customer-managed DNS. 2. Use `custom_tls.enabled = true` with a provided wildcard certificate. 3. Use an internal or mirrored container registry. 4. Use an internal Git service for manifests when the environment is disconnected or tightly controlled. 5. Use `openebs-local` or the cluster's local CSI for `RWO`. 6. Use `nfs-client` or another true shared-storage class for `RWX`. 7. Keep the standard BullSequana AI repository structure under local mirrored prefixes. This keeps the deployment aligned with the reference on-prem operating model without forcing cloud-specific dependencies into the first baseline. Secret Handling [#secret-handling] Real BullSequana hardware configurations often contain: * registry credentials * private Git credentials * wildcard certificates and private keys * Keycloak client secrets * database passwords * MinIO and application secrets Those values should never be copied into shared documentation or committed into example files. Use placeholder values in docs and keep the real materials only in the actual secret-management and deployment workflow. Validation Checklist [#validation-checklist] Before applying a BullSequana hardware or on-prem deployment, validate these questions: 1. Does the cluster expose the actual `RWO` and `RWX` storage classes you plan to use? 2. Is a shared `RWX` class available for components that need shared storage semantics? 3. Does `base_domain` match the DNS suffix that will be published for platform ingresses? 4. Is the wildcard certificate already issued for that domain? 5. Is `custom_tls` populated with the correct base64-encoded materials? 6. Is the internal registry reachable from all cluster nodes? 7. Are the Git repository, branch, and path correct for the manifests Argo CD should reconcile? 8. Is there a clear operational decision for DNS record management given the current provider-specific `external-dns` implementation? Related Pages [#related-pages] * [Choose a Deployment Model](/docs/deployment/deployment-options) * [Prerequisites](/docs/deployment/prerequirements) * [Configuration Model](/docs/deployment/configuration-model) * [Before You Start](/docs/deployment/setup-context)