Prerequisites
Before you run the installer, make sure your AWS account and identity provider are ready. The installer runs a read-only preflight check, but 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 administrator credentials | For the account and region you are deploying into. The installer creates networking, data stores, and compute. |
| 2 | A workstation with Docker and Python 3 | Docker must be running; Python 3 with the AWS SDK (boto3) installed. 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 | AWS Bedrock model access | Enabled in your account for the required models (below). |
| 8 | A Neo4j decision | Choose self-hosted (Studio runs it for you — nothing to prepare) or external/BYO (you provide your own Neo4j). 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 administrator-level credentials for the target account and region, exported in your shell (for example via environment variables or an AWS named profile). 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.
Workstation tooling
The machine that runs the installer needs:
- Docker, running — the installer loads the Studio image and pushes it to your registry.
- Python 3 with the AWS SDK (
boto3) and the AWS CLI available. - The unzipped release bundle, with all files 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.
AWS Bedrock model access
Studio performs model inference on AWS Bedrock in your account. Before deploying, enable account access to the model families Studio uses:
- Anthropic Claude — Sonnet, Haiku, and Opus (used for agent reasoning across speed/quality tiers).
- Cohere Embed (used for embeddings).
The exact model versions for a given release are pinned by that release; the preflight check verifies access and that your token quotas are sufficient. Enable model access in the Bedrock console for your region before you start.
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.
Neo4j (self-hosted or bring-your-own)
Knowledge Graphs are stored in Neo4j. At install time you choose one of two modes — either way the graph lives in your AWS account and never leaves it:
- Self-hosted (managed by Studio) — the default, 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.
- External (bring your own) — you operate your own Neo4j (any compatible deployment reachable from the Studio network on port 7687). The installer finishes without it, and you connect it afterward with
studioctl neo4j. Your external Neo4j is yours to operate, back up, and terminate; the installer never touches it.
You can switch modes later, though moving an existing graph between a self-hosted and an external instance is a manual data migration.
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 PrometheusRL 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.