Prerequisites

Before you run the installer, make sure your AWS account and identity provider are ready. studioctl runs a hard prerequisite check at the very start of every install and update — it confirms the Docker daemon is running, Python 3.9 or newer is available, the boto3 package is installed, and the downloaded bundle tarballs are present, and it stops with a clear remediation message if anything is missing. It also runs a read-only preflight check of your AWS account. Gathering everything below first makes for a smooth, single-pass deployment. Work through this checklist with whoever administers your cloud and your identity provider.

At a glance

#	Requirement	Notes
1	AWS credentials for the target account/region	With the permissions in Required IAM permissions. Blanket admin is not required; the installer creates networking, data stores, and compute.
2	A workstation with Docker and Python 3.9+	Docker must be running; Python 3.9 or newer with the AWS SDK (boto3) installed and the AWS CLI/credentials available. The installer loads and pushes a container image.
3	The Studio release bundle	Downloaded from the Console, unzipped, intact. See Downloading Studio.
4	A License Token	Created in the Console and copied at creation time. See License Keys.
5	A domain you control	You will point this domain at the load balancer after deploy.
6	An ACM certificate	In the same region, in ISSUED state, covering your domain.
7	Amazon Bedrock model access	Enabled in your account for the required models (below). You also choose which model fills the Sonnet (runner) and Opus (planner) classes.
8	Neo4j (self-hosted)	Studio runs it for you — nothing to prepare. No Marketplace subscription is required.
9	A SAML 2.0 identity provider	One you administer; sign-in to Studio is SSO-only.
10	A globally-unique Cognito domain prefix	Must be unique across all of AWS.

Details

AWS account and credentials

Deploy with credentials for the target account and region, exported in your shell (for example via environment variables or an AWS named profile), carrying the permissions listed in Required IAM permissions. Everything is created in one account and one region. Choose the region deliberately — it determines where your data resides and which Bedrock residency zone applies.

Supported regions

Studio may only be deployed into AWS regions that serve the US or EU Amazon Bedrock geographic (cross-Region) inference profiles for the Claude models it uses — that is what keeps inference within your chosen residency zone. studioctl blocks any other region before it starts, and the preflight check confirms per-model access in the region you pick.

Zone	Supported regions
US	us-east-1 (N. Virginia), us-east-2 (Ohio), us-west-2 (Oregon)
EU	eu-west-1 (Ireland), eu-west-2 (London), eu-west-3 (Paris), eu-central-1 (Frankfurt), eu-central-2 (Zurich), eu-north-1 (Stockholm), eu-south-1 (Milan), eu-south-2 (Spain)

us-west-1 (N. California) is not supported — it is not a destination region for the US Bedrock inference profile. If you pass an unsupported region, studioctl stops with the list above before making any changes.

Required IAM permissions

studioctl prints an at-a-glance summary of the services it touches at the start of an install or update and points back here for the exact list. Blanket administrator access is not required. The authoritative, copy-pasteable permission list below is grouped by lifecycle phase so you can grant exactly what each operation needs.

Two notes that scope this down further:

• The installer never touches DNS — you create the load-balancer record yourself. Route 53 permissions are not required.
• The installer never creates certificates — you bring your own ACM certificate. It only reads ACM. acm:RequestCertificate and related write actions are not required.

Because the installer provisions everything through CloudFormation, the deploying principal must be able to create, update, and delete the underlying resources that the stacks manage. The lists below are the concrete actions studioctl and its CloudFormation stacks exercise.

Preflight (read-only)

Run at the start of every install and update; these are all read/list/describe calls:

sts:GetCallerIdentity
cloudformation:ListStacks
cloudformation:DescribeStacks
bedrock:ListFoundationModels
servicequotas:GetServiceQuota
dynamodb:ListTables
dynamodb:DescribeTable
s3:ListAllMyBuckets
ecr:DescribeRepositories
cognito-idp:ListUserPools
cognito-idp:DescribeUserPoolDomain
secretsmanager:ListSecrets
sqs:ListQueues
ec2:DescribeNatGateways
elasticache:DescribeCacheClusters
acm:ListCertificates
acm:DescribeCertificate

Install & Update

Drives the four CloudFormation stacks (change-set based, with CAPABILITY_NAMED_IAM and CAPABILITY_AUTO_EXPAND), pushes the container image, seeds secrets and the SPA, and rolls the ECS services:

# CloudFormation (orchestration)
cloudformation:CreateChangeSet
cloudformation:DescribeChangeSet
cloudformation:ExecuteChangeSet
cloudformation:DeleteChangeSet
cloudformation:ListChangeSets
cloudformation:DescribeStacks
cloudformation:DescribeStackEvents
cloudformation:ContinueUpdateRollback
cloudformation:DeleteStack            # only to clear a failed initial create (ROLLBACK_COMPLETE)

# IAM (CloudFormation creates the task/exec roles + instance profiles)
iam:CreateRole / iam:DeleteRole / iam:GetRole / iam:TagRole
iam:PutRolePolicy / iam:DeleteRolePolicy / iam:GetRolePolicy
iam:AttachRolePolicy / iam:DetachRolePolicy
iam:CreateInstanceProfile / iam:DeleteInstanceProfile
iam:AddRoleToInstanceProfile / iam:RemoveRoleFromInstanceProfile
iam:PassRole                          # to hand the task/exec roles to ECS

# ECR (image push)
ecr:GetAuthorizationToken
ecr:DescribeImages
ecr:BatchCheckLayerAvailability
ecr:InitiateLayerUpload / ecr:UploadLayerPart / ecr:CompleteLayerUpload
ecr:PutImage

# S3 (deploy artifacts, SPA upload, private bucket)
s3:HeadBucket / s3:CreateBucket
s3:PutBucketEncryption / s3:PutBucketVersioning / s3:PutBucketPublicAccessBlock
s3:PutObject / s3:GetObject / s3:DeleteObject

# Secrets Manager (connector creds + internal secrets)
secretsmanager:CreateSecret / secretsmanager:PutSecretValue / secretsmanager:GetSecretValue

# ECS (roll the services)
ecs:ListServices / ecs:DescribeServices / ecs:DescribeTaskDefinition / ecs:UpdateService

# DynamoDB (activity-table guard + table updates)
dynamodb:Scan / dynamodb:UpdateTable

# Resources CloudFormation provisions on your behalf (create/update/delete):
ec2 / vpc (VPC, subnets, route tables, gateways, security groups, ENIs, launch templates)
elasticloadbalancing (ALB, target groups, listeners)
ecs (cluster, services, task definitions)
elasticache (Redis), efs (file systems + mount targets)
cognito-idp (user pool + domain), logs (log groups)
ssm (parameters), sns (topics), sqs (queues), events (rules)
application-autoscaling (service scaling), lambda (helper functions)

Teardown (only if you run studioctl teardown)

Deletes the stacks and then sweeps any straggler resources. Needs Delete*/Describe* on every service above, most notably:

cloudformation:DeleteStack / cloudformation:DescribeStackEvents
ec2:Delete* (NatGateway, InternetGateway, Subnet, RouteTable, SecurityGroup, Vpc, NetworkInterface)
elasticache:DeleteReplicationGroup / elasticache:DeleteCacheSubnetGroup
efs:DeleteMountTarget / efs:DeleteFileSystem
elasticloadbalancing:DeleteLoadBalancer / DeleteTargetGroup
ecr:BatchDeleteImage / ecr:DeleteRepository
s3:DeleteObjects / s3:DeleteBucket / s3:GetBucketLocation / s3:ListObjectVersions
dynamodb:DeleteTable
secretsmanager:DeleteSecret
cognito-idp:DeleteUserPoolDomain / cognito-idp:DeleteUserPool / cognito-idp:DescribeUserPool
lambda:DeleteFunction
logs:DeleteLogGroup
ssm:DeleteParameters
sns:DeleteTopic / sqs:DeleteQueue / events:DeleteRule
autoscaling:UpdateAutoScalingGroup / autoscaling:DeleteAutoScalingGroup
ec2:DeleteLaunchTemplate
iam:DeleteRolePolicy / iam:DeleteInstanceProfile / iam:DeleteRole

If a required action is missing, studioctl stops with a FATAL message that names the exact missing service:Action and the operation it failed in, then resumes from where it stopped once you grant it and re-run — so you can iterate toward a tight policy without re-doing completed work.

Workstation tooling

The machine that runs the installer needs the following local packages and tools — studioctl checks for them before it starts and stops with a remediation message if any are missing:

• Docker, running — the installer loads the Studio image and pushes it to your registry.
• Python 3.9 or newer.
• The boto3 Python package (install with pip install boto3).
• The AWS CLI with credentials configured for the target account and region.
• The unzipped release bundle, with all files (including the bundle tarballs) intact.

Domain and TLS certificate

You bring a domain you control (for example studio.yourcompany.com). You also need an AWS Certificate Manager (ACM) certificate that:

• is in the same region as your deployment,
• is in ISSUED state, and
• covers your chosen domain (exact or wildcard).

You will create a DNS record pointing your domain at the load balancer after the deploy completes (the installer prints the exact target). DNS is never modified for you.

Amazon Bedrock model access

Studio performs model inference on Amazon Bedrock in your account. Before deploying, enable account access to the models Studio uses:

• Anthropic Claude — a Sonnet-class and an Opus-class model (used for agent reasoning — Sonnet runs, Opus plans).
• Cohere Embed (used for embeddings).

The preflight check verifies access to the models you choose and recommends a tokens-per-day quota floor for each. Enable model access in the Bedrock console for your region before you start.

Choosing your models

Studio runs two model classes: a Sonnet class (the runner tier) and an Opus class (the planner tier). You pick which concrete Bedrock model fills each one at install (and can change them later — see Updating Studio):

• Sonnet class — defaults to Claude Sonnet 4.6 (the validated runner).
• Opus class — choose Claude Opus 4.6 (the validated planner, default) or Claude Opus 4.8 (newest/strongest; verify Bedrock access and quota in your account first).

Both classes also accept an advanced "enter any Bedrock model id" option. Select them interactively, or non-interactively with --sonnet-model / --opus-model (or the matching --config entries). Claude Haiku is no longer used at runtime — the tiering policy is a Sonnet runner plus an Opus planner.

Which models Studio uses, and where

Studio uses three Amazon Bedrock model roles. Each one resolves at run time to the us.* or eu.* Bedrock inference profile that matches the residency zone you choose at deploy — there is no global or cross-zone routing.

Model (Bedrock)	Where it is used
Sonnet class (default Claude Sonnet 4.6)	The runner tier: planning, knowledge-graph retrieval and build, connector guide enrichment, document parsing, conversation summarization, and high-volume node/task work.
Opus class (default Claude Opus 4.6; or Opus 4.8)	The planner tier: workflow conditional (branching) nodes and deeper planning.
Cohere Embed v4	Knowledge-graph embeddings (1536-dimension vectors). Fixed — not a customer choice.

Each model is invoked through the inference profile for your zone — for a US deployment the us.* profiles (e.g. us.anthropic.claude-sonnet-4-6), for an EU deployment the eu.* profiles. If a required profile is missing or its zone does not match your region, Studio fails closed rather than route inference out of zone.

Inference residency zone

Studio pins model inference to a single residency zone — typically us or eu — so inference stays within that boundary. You can set the zone explicitly during deploy, or let the installer derive it from your region. There is no global/cross-zone routing.

AWS service quotas

The preflight check verifies your account quotas before deploying. The key ones:

• Amazon Bedrock tokens-per-day for the models you chose — the preflight recommends a per-model tokens/day floor for your selected Sonnet and Opus models (plus Cohere Embed) and warns if your account's applied quotas look low. (A custom/non-catalog model id can't be auto-checked, so the preflight reminds you to confirm its access and request an adequate quota manually.)
• Fargate concurrent vCPU (L-3032A538) — at the default standard tier Studio's running fleet is about 76 vCPU, and a new AWS account's default quota is 140 vCPU, so no increase is required on a default account. (Updates stop old tasks before starting new ones, so a deploy never temporarily doubles the fleet.) The preflight computes the exact fleet size for the sizing tier you pick and only flags an increase if your account's quota has been lowered below it. See Infrastructure costs and sizing.
• AWS Lambda concurrency and memory — execution environments and other code-interpreter features run on Lambda in your account. New AWS accounts start with reduced Lambda concurrency and per-function memory quotas, which AWS raises automatically as your usage grows. On a brand-new account you may be limited in how large an environment you can provision or how many can run at once until those quotas increase. See the AWS Lambda quotas documentation.

Neo4j (self-hosted)

Knowledge Graphs are stored in self-hosted Neo4j, managed by Studio — the graph lives in your AWS account and never leaves it. This is a zero-touch option: Studio runs single-node Neo4j Community as a Fargate service in your VPC, backed by encrypted, multi-AZ EFS storage. There is nothing to prepare in advance — the installer generates the password, provisions the storage, and starts the service for you. No Marketplace subscription and no instance to launch.

SAML 2.0 identity provider

Sign-in to Studio is single sign-on only — there is no username/password or self-signup. You need a SAML 2.0 identity provider you administer (for example Okta, Microsoft Entra ID, or Google Workspace). You will register Studio as a service provider and supply its metadata during deploy. The details are in Single Sign-On (SAML).

Cognito domain prefix

Sign-on is brokered by an Amazon Cognito user pool, which needs a domain prefix that is globally unique across all of AWS (for example yourcompany-alphaagent). The preflight check verifies availability; have a couple of candidates ready in case your first choice is taken.

What you do not need

• You do not give Prometheus Research Labs any access to your account.
• You do not manage servers — the backend runs on serverless Fargate.
• You do not edit infrastructure templates — the installer drives them.

Next

Once this checklist is satisfied, continue to the Deploy Walkthrough.