# Deploy and operate (/docs/operate)



Deployment is the beginning of the service lifecycle, not the end. This area connects installation guidance with the administrative and operational work required to keep BullSequana AI reliable after rollout.

## Recommended path [#recommended-path]

<Callout type="info" title="First production deployment">
  [Choose a deployment model](/docs/deployment/deployment-options) → [Prepare the environment](/docs/deployment/setup-context) → [Complete prerequisites](/docs/deployment/prerequirements) → [Run the deployment sequence](/docs/deployment/playbooks/deployment-sequence) → [Establish operations](/docs/administration)
</Callout>

## Lifecycle [#lifecycle]

### 1. Plan [#1-plan]

Decide where the platform will run, who owns each external dependency, and which identity, DNS, certificate, registry, storage, and network services must exist before installation. Record the acceptance criteria and rollback boundary before making changes.

Start with [deployment options](/docs/deployment/deployment-options) and [before you start](/docs/deployment/setup-context).

### 2. Prepare [#2-prepare]

Validate cluster access, storage, registry delivery, DNS, trust, identity, and hardware capacity. Treat prerequisites as testable interfaces between the platform and the target environment.

Use [prerequisites](/docs/deployment/prerequirements), [minimum requirements](/docs/deployment/minimum-requirements), and the relevant [environment guide](/docs/deployment/environments).

### 3. Deploy and verify [#3-deploy-and-verify]

Apply configuration through the supported GitOps and platform tooling path. Verify reconciliation, ingress, identity, storage, observability, and the first AI request before handing the installation to users.

Use the [deployment sequence](/docs/deployment/playbooks/deployment-sequence), [GitOps workflow](/docs/deployment/gitops-workflow), and [Platform CLI](/docs/deployment/platform-cli).

### 4. Administer and observe [#4-administer-and-observe]

Separate provider-wide, tenant-wide, team-level, and service-owner responsibilities. Establish dashboards, alerts, logs, traces, audit evidence, capacity reviews, and a repeatable incident path.

Use [Administration and operations](/docs/administration), [Foundation observability](/docs/foundation/observability-and-audit), and [Troubleshooting](/docs/troubleshooting).

### 5. Upgrade and recover [#5-upgrade-and-recover]

Before an upgrade, confirm compatibility, backup scope, validation steps, and the rollback decision point. Recovery plans must include platform configuration, stateful services, external dependencies, and the evidence needed to know that service has been restored.

Use the [upgrade process](/docs/deployment/playbooks/upgrade-and-release-process) and [backup and disaster recovery](/docs/deployment/playbooks/backup-and-disaster-recovery).

## Responsibility map [#responsibility-map]

| Role                   | Primary responsibility                                                           |
| ---------------------- | -------------------------------------------------------------------------------- |
| Infrastructure owner   | hardware, network, storage, Kubernetes, and cloud dependencies                   |
| Platform engineer      | platform configuration, reconciliation, health, capacity, upgrades, and recovery |
| Provider administrator | installation-wide settings, tenant lifecycle, and hard limits                    |
| Tenant administrator   | federation, teams, members, and delegated access inside one tenant               |
| Security owner         | access review, isolation requirements, evidence, sovereignty, and compliance     |
| Service owner          | onboarding, entitlements, adoption, consumption, and service outcomes            |

For a step-by-step first deployment, use the [deploy and operate guided path](/docs/get-started/deploy-and-operate).