BullSequana Hardware

A practical on-premises baseline for BullSequana AI on BullSequana hardware or similar controlled infrastructure

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

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

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

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

common_config = {
  ingressclassname             = "nginx"
  imagepullsecret              = "registry-secret"
  base_domain                  = "<cluster-subdomain>.<customer-domain>"
  wildcard_cert_secret_name    = "wildcard-tls"
  rwo_storageclass             = "openebs-local"
  rwx_storageclass             = "nfs-client"
  realm_name                   = "dataplatform"
  registry                     = "<internal-registry-host>"
  registry_platform_repository = "<mirror-prefix>/coreai/platform"
  registry_backend_repository  = "<mirror-prefix>/coreai/backend"
  registry_portal_repository   = "<mirror-prefix>/coreai/portal"
  registry_helm_repository     = "<mirror-prefix>/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-user>@<internal-git-host>/<path-to-manifests>.git"
  git_branch   = "<branch-name>"
  git_path     = "data-platform"
}

dockerconfigjson = "<base64-dockerconfigjson>"

custom_tls = {
  enabled = true
  ca_crt  = "<base64-ca-crt-or-empty>"
  tls_crt = "<base64-wildcard-tls-crt>"
  tls_key = "<base64-wildcard-tls-key>"
}

What This Baseline Assumes

This baseline assumes a few explicit operational choices.

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

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

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:

registry = "<internal-registry-host>"

while keeping the same platform repository structure under local mirrored prefixes:

<mirror-prefix>/coreai/platform
<mirror-prefix>/coreai/backend
<mirror-prefix>/coreai/portal
<mirror-prefix>/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

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

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

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`

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:

DNS records are managed outside the current Terraform layer.
The deployment layer is adapted for the real on-prem DNS provider.
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

For a practical BullSequana Hardware baseline, start with this model:

Use internal or customer-managed DNS.
Use custom_tls.enabled = true with a provided wildcard certificate.
Use an internal or mirrored container registry.
Use an internal Git service for manifests when the environment is disconnected or tightly controlled.
Use openebs-local or the cluster's local CSI for RWO.
Use nfs-client or another true shared-storage class for RWX.
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

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

Before applying a BullSequana hardware or on-prem deployment, validate these questions:

Does the cluster expose the actual RWO and RWX storage classes you plan to use?
Is a shared RWX class available for components that need shared storage semantics?
Does base_domain match the DNS suffix that will be published for platform ingresses?
Is the wildcard certificate already issued for that domain?
Is custom_tls populated with the correct base64-encoded materials?
Is the internal registry reachable from all cluster nodes?
Are the Git repository, branch, and path correct for the manifests Argo CD should reconcile?
Is there a clear operational decision for DNS record management given the current provider-specific external-dns implementation?

BullSequana Hardware

On this page