Prerequisites

Before BullSequana AI can be deployed in a controlled customer environment, a few things need to be clear and available first.

Some of them are true external prerequisites:

• a working Kubernetes environment
• storage, networking, DNS, and certificate ownership decisions
• a local GitLab repository for manifests
• a local Harbor registry for images and Helm artifacts

Others are platform-managed shared services that BullSequana AI can deploy itself, but only if their required inputs are already known.

That distinction matters.

The deployment should not start with uncertainty around cluster access, storage classes, registry reachability, DNS ownership, or the manifest source of truth.

Kubernetes And Runtime Foundations

Kubernetes is the operating substrate of the platform.

Before bootstrap, the target environment should already provide:

• a reachable Kubernetes cluster
• cluster-admin or equivalent installation access
• a working kubeconfig and operational access path
• node capacity aligned with the intended platform scope
• working persistent storage classes
• a chosen ingress strategy

This is the true base layer. Without it, the rest of the platform delivery chain is irrelevant.

Cluster access

The deployment process assumes operators can:

• connect to the cluster
• create namespaces and cluster-scoped resources
• install operators and shared controllers
• allow Argo CD to reconcile the application layer

Storage classes

The current coreai-platform Terraform layer treats storage-class selection as a critical input through:

• common_config.rwo_storageclass
• common_config.rwx_storageclass

The example file explicitly calls out that:

• RWO is needed for databases and single-pod persistent services
• RWX is needed for shared storage workflows
• some components such as Docling benefit from or require ReadWriteMany

So before deployment, the cluster should already expose valid storage classes for both access patterns, or there should be a conscious fallback decision.

GPU and node capacity

If CoreAI inference services are in scope, the environment should also already have:

• GPU-capable nodes where needed
• a scheduling and isolation strategy
• any required driver or node-feature setup already solved at cluster level

Those are infrastructure prerequisites, not late-stage application settings.

Networking, DNS, And Certificates

The platform also expects a clear external access model.

The current deployment input model requires:

• common_config.base_domain
• common_config.ingressclassname
• common_config.wildcard_cert_secret_name

So before deployment, these questions should already be answered:

• which ingress controller class will be used
• which DNS zone will host platform endpoints
• who owns DNS record management
• whether certificates are provided directly or issued through automation
• whether the environment needs cloud-specific DNS integration

DNS ownership

The key prerequisite is not just a domain name. It is a clear DNS ownership model.

The deployment team must know:

• which base domain will be used
• who can create and update records in that zone
• whether that will be done manually, by platform automation, or by another enterprise DNS process

Certificate strategy

The same is true for TLS.

Before deployment starts, the team should know whether the environment will use:

• directly provided wildcard TLS material through custom_tls
• or an automation path such as DNS-01, if the environment-specific integration supports it

The deployment should not begin while the certificate model is still ambiguous.

Delivery Systems

The reference delivery model also assumes two local control points for software delivery:

• GitLab
• Harbor

These are not optional convenience tools in the reference model. They are the local control points for manifests, images, and Helm artifacts that Argo CD and the platform rollout depend on.

GitLab

GitLab is used as the local manifest and delivery source.

In practice, it gives the deployment a customer-controlled or environment-controlled place for:

• the platform manifest repository
• environment-specific values and overlays
• reviewed change history
• CI or automation around manifest preparation if needed

The key point is that BullSequana AI should not depend on editing live cluster resources by hand as the primary operating model.

Instead, the desired state should live in a Git repository that Argo CD can reconcile.

What to prepare in GitLab

At minimum, GitLab should provide:

• a repository for the platform manifests
• credentials or tokens that Argo CD can use to read that repository
• the correct branch for the target environment
• the correct manifest path inside the repository

Operationally, the important settings are:

• repository visibility and access model
• protected branches if the customer wants controlled promotion
• environment-specific branch or folder strategy
• CI or manual review process for manifest changes

These inputs map directly to the deployment git_config values:

• git_repo_url
• git_branch
• git_path

Harbor

Harbor is used as the local OCI registry for platform delivery.

It is the place where the deployment expects to find:

• Docker images for BullSequana AI components
• Helm charts or Helm-packaged artifacts used by the platform delivery chain
• proxied or replicated copies of the approved upstream artifacts

This is especially important in:

• air-gapped environments
• security-sensitive environments
• sovereign or customer-controlled environments

The operational principle is simple: the customer environment should pull platform artifacts from its own trusted registry path, not directly from a remote cloud source during bootstrap.

Why we proxy to Harbor

BullSequana AI delivery uses a proxy or replication pattern into Harbor for the same reason that manifests are localized in GitLab: controlled, reviewable, environment-owned delivery.

In practice, Harbor is used to proxy or mirror:

• pre-vetted Docker images
• pre-verified Helm charts and related artifacts

That gives several benefits:

• a stable local source of truth for deployment artifacts
• reduced dependence on external network access during rollout
• better alignment with air-gapped and restricted-network environments
• clearer security and governance boundaries
• easier traceability for what was actually promoted into the environment

What to prepare in Harbor

At minimum, Harbor should provide:

• a reachable registry hostname
• TLS for the registry endpoint
• admin or automation credentials
• project structure for BullSequana AI artifacts
• image pull credentials that can be converted into cluster pull secrets

Operationally, the important settings are:

• project or namespace structure for the platform repositories
• replication or proxy-cache rules from the approved upstream registry path
• vulnerability scanning and retention settings according to customer policy
• RBAC for the delivery and operations teams

The repository structure should stay aligned with the deployment configuration model, for example:

• coreai/platform
• coreai/backend
• coreai/portal
• coreai/helm

Platform-Managed Shared Services

Some important software components are usually deployed by the BullSequana AI platform itself rather than being mandatory preinstalled services.

The current coreai-platform defaults enable several of them out of the box, including:

• Argo CD
• Sealed Secrets
• cert-manager
• external-dns
• ingress-nginx
• Keycloak

That means the environment does not necessarily need those components preinstalled manually.

But it does need the prerequisites those components rely on.

Argo CD

Argo CD is part of the platform-managed delivery layer, but it still needs:

• a reachable manifest repository
• valid Git credentials
• the correct repository URL, branch, and path

Without GitLab or an equivalent manifest source, Argo CD has nothing useful to reconcile.

Ingress controller

The current defaults enable ingress-nginx and expect an ingress class through common_config.ingressclassname.

So even if the platform deploys the ingress controller itself, the deployment still needs:

• a chosen ingress model
• routable load-balancer or edge exposure strategy
• DNS aligned with the exposed ingress endpoints

external-dns

external-dns is a platform-managed component in the current Terraform defaults.

But whether it can actually manage DNS depends on provider-specific inputs and environment support.

So the real prerequisite is not “external-dns must already exist”. The real prerequisite is:

• the DNS ownership model must be known
• the environment-specific DNS integration must be valid for the target platform

cert-manager

cert-manager is also enabled by default in the current Terraform layer.

Again, the prerequisite is not necessarily a preinstalled cert-manager instance. The prerequisite is:

• a clear certificate issuance model
• the right issuer inputs
• or directly supplied TLS material if the environment uses custom_tls

Keycloak

The platform can deploy Keycloak, but the environment still needs early decisions around:

• standalone identity versus federation
• expected realm and client model
• who will manage initial identity and access settings

So the software may be platform-managed, but the identity model is still a prerequisite decision.

Network And Connectivity Constraints

Another prerequisite area is external reachability.

Before deployment, the team should know:

• whether the cluster has outbound internet access
• whether a proxy is required
• whether artifact delivery is fully air-gapped
• whether image and chart access must stay entirely local

This matters because the deployment input model also includes optional proxy settings in common_config.

How These Pieces Fit Together

The practical dependency chain is:

1. Kubernetes provides the runtime substrate.
2. storage, ingress, DNS, and certificates provide the operational foundation.
3. Harbor exposes the trusted local artifact path.
4. GitLab exposes the trusted local manifest path.
5. Argo CD reads manifests from GitLab.
6. the cluster pulls images and charts through Harbor.
7. platform-managed shared services come up on top of those foundations.

If any of those layers is missing or misaligned, bootstrap can fail even when the cluster itself is technically running.

Practical Readiness Checklist

Before beginning deployment, validate these questions:

1. Is the Kubernetes cluster reachable with installation-level access?
2. Are valid RWO and RWX storage classes already available?
3. Is there a chosen ingress strategy and ingress class?
4. Is the base domain and DNS ownership model clear?
5. Is the certificate strategy clear: supplied TLS or automated issuance?
6. Is the Harbor registry reachable, trusted, and populated with the approved artifacts?
7. Is the GitLab repository reachable and aligned with the intended manifests branch and path?
8. Are image pull credentials ready for cluster use?
9. Are proxy or restricted-network constraints understood before bootstrap starts?
10. If CoreAI inference is in scope, is the GPU capacity already available?

Related Pages

• Before You Start
• Configuration Model
• BullSequana Hardware
• Artifact Delivery with Harbor