# Install

> The vendor installs the platform into your dedicated AWS account from its deployment pipeline, in a window booked with you.

_How-to · Updated 2026-10-19 · Describes release 0.1.164_

Evidence reviewed **8 October 2026** on **0.1.130** (the 16 October 2026 handover build; see the [release notes](/help/release-notes.md)); the steps are unchanged through 0.1.133.

The vendor installs the platform into your dedicated AWS account from its deployment pipeline, in a window booked with you. In the handoffs below, you run step 2 (the bootstrap in AWS CloudShell), step 2b if you want Claude, and step 8 (first login and first connections); you also stay reachable during step 5. Steps 3 and 6 belong to the owner of the DNS zone for the platform's host name: you, for a host name in your domain. The vendor runs steps 1, 4, 5 and 7. An installation you run yourself is not covered by this procedure ([runbook §7](/help/ops-installation-runbook.md#7-not-covered)).

Use [Deployment runbook §0–2](/help/ops-installation-runbook.md#0-the-whole-install) as the installation procedure. This chapter is the operator's handoff and acceptance checklist. Its commands come from that runbook's rehearsal path; they are not a second deployment mechanism.

Book the window and return the step 2 apply JSON through the support channel in [Support and escalation](/help/ops-support-and-escalation.md#contacts-and-commitments).

## Before booking the window {#before-booking-the-window}

1. Confirm a dedicated AWS account, install region, two supported availability zones, organization restrictions and sufficient On-Demand vCPU quota. The bootstrap warns below 8 vCPU.
2. Name the cluster emergency-access principal. An account root cannot assume a role and cannot serve as the usable EKS emergency-access principal; provide the approved `AIOPS_ADMIN_ROLE_ARN` when needed.
3. Agree the model endpoint and region. Bedrock runtime roles invoke models; they cannot accept Marketplace model agreements. Account administrators complete provider onboarding separately (step 2b). The bootstrap's default is Claude (`anthropic.claude-sonnet-5`) through a geographic Bedrock inference profile, and Nova Pro when the account cannot use Claude.
4. Name the DNS owner, deployment approver and RDS alarm recipient. The email recipient must confirm the SNS subscription before it can deliver alarms.
5. Confirm the path to private estate endpoints: VPC routing or a private-network agent. The default deployment keeps a NAT gateway.
6. Review and accept the deployer-role risk. The `aiops-deployer` role that step 2 creates can attach any policy to itself, so in practice it can make itself administrator of the account; no permissions boundary is built. Containment is the dedicated account and the role's trust: only the vendor pipeline can assume it, with your ExternalId and a SourceIdentity that names the operator, so every session lands in your CloudTrail under that name ([runbook §1.4](/help/ops-installation-runbook.md#1-4-what-the-deploy-role-can-do)).

The booked window is for step 5; steps 6 and 7 follow it. In the rehearsal, step 5 took about 27 minutes from approval to the passing health gate and the step 7 smoke took 34 seconds. A new certificate, DNS changes, approval waits and first-use model onboarding were not measured, and no end-to-end duration exists, so size the window from these figures and your own approval and DNS lead times ([Timings and scope of proof](/help/ops-install.md#timings-and-scope-of-proof)).

## Run the eight handoffs {#run-the-eight-handoffs}

| Step | Action | Acceptance evidence |
|---|---|---|
| 1 | Vendor mints the per-install ExternalId and secrets, provides bootstrap zip and checksums; sends ExternalId separately | Vault copy of the secrets file; verified bootstrap bundle |
| 2 | Customer runs bootstrap plan and apply in CloudShell in the installation region | Apply JSON with `deploy_role_ready: true`; correct account and region; usable admin principal |
| 2b | Only to use Claude: when `plan` prints `next step for Claude:` (`model.anthropic_next_step` in its JSON), a customer account administrator completes the step it names, for example Anthropic's use-case form in the Bedrock console or the two printed `aws bedrock` commands that accept the model agreement (AWS CLI 2.27.42 or later), then re-runs `plan` and `apply`. The bootstrap prints these commands and never runs them; without them it recommends Nova Pro | Apply JSON whose `model.recommended` names the Claude inference profile, sent before step 4 (which configures the model it names) |
| 3 | DNS owner adds the ACM validation CNAME | Certificate `ISSUED` before HTTPS deployment |
| 4 | Vendor renders the customer branch, creates/updates the Azure DevOps secret group and Environment, and grants registry pulls | Branch reviewed; named Environment approver; current values and secret group |
| 5 | Vendor queues `deploy-customer.yml` with the approved image tag and `bootstrapDb=true`; the named approver reads Plan, then approves | Stack deployed; `deploy-log.json`; successful HTTPS `/healthz` gate |
| 6 | DNS owner adds the platform CNAME to the ALB target | Correct public DNS, DNS-only, valid HTTPS |
| 7 | Vendor prices the exact model id and runs the supplied smoke | Real-model usage, non-zero booked cost, non-empty RCA and runner claim |
| 8 | Customer logs in, resets the initial password, connects the IdP, estate read access and alert sources | First keyless connection Test passes; named owners for connections and intake; the step 7 webhook token is in your secret store, or replaced by one you minted |

The customer-side commands below are from runbook §2, Step 2. Set the three values from the approved handoff before running them; `example-org` is an example workspace name throughout these chapters.

```bash
unzip aiops-bootstrap.zip
export AIOPS_ACCOUNT_ID=111122223333
export AIOPS_EXTERNAL_ID='replace-with-the-issued-external-id'
export AIOPS_HOST=aiops.example.com
bash deploy/customers/bootstrap.sh plan
bash deploy/customers/bootstrap.sh apply
```

Read the plan and account check before apply. Supply `AIOPS_ADMIN_ROLE_ARN` for the approved emergency-access role if the caller needs one. Send the saved apply JSON back to the release team through the support channel ([Support and escalation](/help/ops-support-and-escalation.md#contacts-and-commitments)); the JSON contains no ExternalId.

## Verify the installation {#verify-the-installation}

Use the smoke procedure in runbook §2, Step 7 from a host that can reach the platform. It creates the first workspace if absent, so use the intended workspace, not a disposable name. The workspace it creates is owned by `admin@local` and belongs to no customer organization; adopt it as the platform console's *Set up your first customer* chapter describes ([ops-start.md](/help/ops-start.md)) instead of creating a second one. The password-file path below is local.

```bash
BASE=https://aiops.example.com TENANT=example-org \
  ADMIN_PASSWORD_FILE=/secure/admin-password.txt scripts/customer-smoke.sh
```

The first smoke mints an intake token and prints it once. Retain it securely; later runs must supply the existing `WEBHOOK_TOKEN` or they rotate intake and break existing senders. Share the incident URL, not the smoke output. At step 7 the token goes straight into your secret store (runbook §2, Step 7). If you do not hold it at step 8, mint a new one before you point alert sources at the platform: in the portal, **Alert intake & tokens → Mint webhook token** (a workspace owner). The smoke's token then stops working.

The documentation site is public by default: `https://aiops.example.com/help/` serves the same guides as the consoles without a sign-in, and `/help/llms.txt` is the index for AI agents; set `AIOPS_PUBLIC_DOCS=false` on the control plane (`extraEnv` in the chart values) to turn it off. Before the platform is installed, an AI agent reads the same procedure from `docs/llms.txt` in the delivered documentation, which lists this chapter as `07-operations/02-install.md`.

For new installs using the 0.1.109-or-later example values, any-account keyless AWS mode lets the guided CloudShell setup create `aiops-<workspace>-read` and `aiops-<workspace>-write` in the account entered by the customer, without a staff preparation step. The read role trusts both platform identities; the write role trusts the control plane only, with the workspace External ID and `sts:TagSession` in the trust policy. A manually created role must be named `aiops-*` without an IAM path.

The platform's own account, private-agent workspaces and existing staff-prepared bindings keep a prepared pair. Staff manages that binding at `/api/aiops/admin/tenants/{id}/cloud-runtime`. Follow the connection procedure for the complete trust and setup requirements.

Test runs on the control plane; investigations run on the runner. A refused Test names the checks and includes AWS's own reason. A passing smoke plus one passing keyless read-connection Test is the installation acceptance described in the deployment runbook; Test alone does not verify runner access.

### The record archive (optional) {#the-record-archive-optional}

Records past the retention window are removed unless the install archives them first. To archive, the infrastructure pipeline applies the `archive` unit before `iam` (a dedicated S3 bucket `<name_prefix>-archive-<account>` with Object Lock governance mode for 5 years, SSE-KMS with its own customer-managed key, versioning, public access blocked, TLS only, object access for the control plane's role alone; `prevent_destroy` on the bucket and the key) and grants the control plane's Pod Identity role `s3:PutObject`/`s3:GetObject` on `tenants/*`, `s3:ListBucket` and `kms:GenerateDataKey`/`kms:Decrypt` through S3 — never a delete. Re-run `bootstrap.sh apply` first: the deployer policy gains the bucket actions. Then set the chart values:

```yaml
config:
  AIOPS_ARCHIVE_BUCKET: "<name_prefix>-archive-<account id>"
  AIOPS_ARCHIVE_REGION: "<installation region>"
```

Leave `secrets.AWS_ACCESS_KEY_ID` empty: the archive refuses credentials resolved from anything but the pod's role. After the rollout the Ops console's **Data retention default** card shows the bucket and `container-role`, and **Records past the window** defaults to **Archive, then remove**. `destroy-customer.yml` keeps the bucket, its key and the unit's state on purpose; deleting them is the break-glass procedure in [Security operations](/help/ops-security-operations.md#the-record-archive).

## Timings and scope of proof {#timings-and-scope-of-proof}

Observed in the **6 October 2026 rehearsal, build 0.1.105**, from the rehearsal timing record for the [deployment procedure](/help/ops-installation-runbook.md). These are measurements, **not an SLA**; phases overlap or sit within the overall interval and must not be added together.

| Interval | Observed time | Boundary |
|---|---|---|
| Bootstrap plan | 14 s | 06:03:30–06:03:44 UTC; read-only check |
| Bootstrap apply | 19 s | 06:03:44–06:04:03 UTC; role/configuration handoff |
| Infrastructure apply | 18 min 21 s | 07:53:23–08:11:44 UTC; stack creation inside Deploy |
| Helm install | 2 min 17 s | 08:13:33–08:15:50 UTC; inside Deploy |
| Approval to passing HTTPS health gate | About 27 min | Approval approximately 07:49 UTC; gate 08:16:27 UTC; includes pipeline scheduling/wait time |
| Real-model smoke | 34 s | 08:27:09–08:27:43 UTC; exit 0 |

The certificate was already ISSUED and was reused. The pull grant also already existed. These figures do not measure a fresh certificate, all vendor setup, customer approval waiting, first-use model onboarding or the entire eight-step process. The published procedure separately records upgrade, rollback and re-upgrade on 7 October at about **7 minutes per run from approval**. Reserve time for the unmeasured handoffs when booking a new installation.

The 8 October restore record confirms a customer-template installation tested on 0.1.108. A fresh account, another region, a new certificate and first-use model agreements each need their own acceptance evidence. Keep the deployment artifact, health result, connection Test and incident URL with the install record.

Sources: [Deployment runbook §1–4](/help/ops-installation-runbook.md), and customer-template restore record.


## Next steps

- Next: [Customer deploy runbook — a fresh AWS account in 8 steps](/help/ops-installation-runbook.md)
- [All Install and operate the platform pages](/help/install-and-operate-the-platform/llms.txt)
- [Documentation home](/help/)