Choose a Deployment Model

BullSequana AI is designed to run in several deployment models, but they are not all equal from an operational standpoint.

The preferred order is:

1. BullSequana hardware
2. Sovereign public cloud
3. Existing GPU infrastructure
4. Hybrid deployment

BullSequana Hardware

This is the reference deployment path.

It is the best fit when the goal is to deploy BullSequana AI as an integrated platform with known hardware characteristics, validated delivery workflows, and a clear operational ownership model from factory preparation to on-site rollout.

Typical benefits:

• optimized sizing for AI workloads
• simpler delivery coordination
• strong alignment between hardware, platform, and support
• faster path to a production-ready environment

Sovereign Public Cloud

This is the next priority when the target environment must stay within a sovereign hosting model while preserving operational control.

Typical examples include providers such as IONOS, OVHcloud, and OUTSCALE, depending on the customer environment and regional requirements.

This model is a good fit when the customer wants:

• local or regional control over infrastructure
• strong data residency positioning
• cloud-style operational flexibility without defaulting to hyperscaler lock-in
• a white-label or service-provider operating model

Existing GPU Infrastructure

BullSequana AI can also be deployed on compatible infrastructure that the customer already owns.

This is useful when the objective is to add a managed AI platform layer without replacing the underlying servers or cluster footprint. It is often the fastest way to introduce the platform into an existing technical landscape, especially when Kubernetes, registry, and networking foundations already exist.

Hybrid Deployment

Hybrid deployment is relevant when workloads need to be split across multiple sites or operating domains.

Typical examples:

• on-premise inference with cloud-based experimentation
• staged migration from existing infrastructure to BullSequana hardware
• different environments for regulated and non-regulated workloads

What Changes Between Environments

The platform architecture stays consistent, but some deployment inputs change by environment:

• storage classes
• DNS and certificate provisioning
• registry and image delivery path
• Git and Argo CD source configuration
• GPU scheduling and node placement
• cloud-specific identity or DNS integration

Current Deployment Automation Notes

The current coreai-platform deployment automation is structured to support modular platform rollout through OpenTofu/Terraform and Argo CD.

Today, the input model already exposes cloud-specific settings for some integrations, especially DNS and certificate automation. That does not change the recommended positioning: BullSequana hardware remains the reference path, and sovereign cloud environments come next when the target operating model requires them.