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); 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).

Use Deployment runbook §0–2 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.

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).

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).

Run the eight handoffs

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.

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); the JSON contains no ExternalId.

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) instead of creating a second one. The password-file path below is local.

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)

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:

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.

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. These are measurements, not an SLA; phases overlap or sit within the overall interval and must not be added together.

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, and customer-template restore record.

Next steps

• Next: Customer deploy runbook — a fresh AWS account in 8 steps
• All Install and operate the platform pages
• Documentation home