Deployment overview and architecture
AlphaAgent Studio is a customer self-deploy product: you download a release bundle from the Console and run a guided installer that provisions Studio entirely inside your own AWS account and region. This page describes what gets created in your account, how the pieces fit together, and how requests and data flow through the system. PrometheusRL never accesses your account.
The deployment model in one picture
You run the installer (python3 studioctl.py install) with your own AWS credentials. It creates a small set of CloudFormation stacks in your account, pushes the Studio application image to your container registry, configures sign-on against your identity provider, and points your domain at the load balancer. Your data never leaves your account except for signed license telemetry to the Console.
What gets deployed into your AWS account
The installer provisions the following AWS resources in your account. Everything below lives under your control, in your region.
| Resource | What it is and why it's there |
|---|---|
| VPC, subnets, and networking | A dedicated virtual network with public and private subnets. Studio's services run in the private subnets; only the load balancer is internet-facing. Optionally a NAT gateway for outbound access. |
| Application Load Balancer (ALB) with an SSO listener | The single internet-facing entry point. Its HTTPS listener enforces single sign-on: every request must be authenticated against your identity provider before it reaches any Studio service. |
| ECS Fargate services | The Studio backend runs as a set of serverless containers on AWS Fargate (ARM64) in the private subnets. There is no server for you to patch or manage. |
| Amazon Cognito user pool | Brokers single sign-on. It is federated to your SAML identity provider; users are admin-provisioned (no public self-signup). See Single Sign-On. |
| Per-environment execution Lambdas | When you create code-execution environments inside Studio, each one is backed by its own AWS Lambda function (alphaagent-env-…) in your account. This is where agent-written code runs, isolated per environment. Created on demand as you build environments. |
| Amazon S3 buckets | Object storage for the Studio web app, agent workspaces, uploaded documents, and other artifacts. All in your account. |
| Amazon DynamoDB tables | The operational data store for agents, swarms, conversations, connectors, sessions, datasets, and more. |
| Amazon ElastiCache (Redis) | In-memory cache for fast, ephemeral state. |
| AWS Secrets Manager | Holds Studio's configuration and your connector credentials and license secret. Nothing sensitive is stored in plaintext in the application config. |
| Amazon ECR (container registry) | Your private registry that holds the Studio application image the installer pushes during deploy. |
| Neo4j (self-hosted or external) | The graph database that stores your Knowledge Graphs. You choose at install time: self-hosted, where Studio runs single-node Neo4j Community as a Fargate service in your VPC backed by encrypted multi-AZ EFS (zero-touch, no Marketplace subscription); or external, where you point Studio at your own Neo4j. Either way the graph stays in your account. |
For a deeper, behavior-level treatment of how these resources handle your data, see What runs in your account and Data residency and security.
External dependency: AWS Bedrock
Studio uses AWS Bedrock for model inference. Bedrock runs within AWS in a residency zone you select (for example us or eu), so model calls stay inside your chosen region boundary. You must enable access to the required models in your account before deploying — see Prerequisites.
How requests and data flow
Every user request enters through the ALB and is gated by single sign-on before it reaches Studio. Agent runs execute against Bedrock for inference and may read your data through connectors, run code in per-environment Lambdas, and query your knowledge graphs in Neo4j — all inside your account.
The data boundary
The defining property of this architecture is that your data stays in your account:
- Agent definitions, conversations, workspaces, datasets, uploaded documents, connector credentials, and knowledge graphs all live in your AWS account (and your Neo4j instance).
- Model inference runs on your AWS Bedrock, pinned to your residency zone.
- The only outbound traffic to PrometheusRL is signed license activation, periodic heartbeats, and usage metering — described in Licensing and Telemetry.
How the stacks are organized
The installer creates the resources above through a few CloudFormation stacks, deployed in order so that each builds on the previous one:
- A foundation stack — networking, data stores, registry, Cognito, and secret placeholders.
- A load balancer stack — the internet-facing ALB and its SSO-enforcing listener.
- A compute stack — the Fargate cluster and the roles Studio runs under.
- A services stack — the Studio service definitions that run on Fargate.
If you chose self-hosted Neo4j, the foundation stack also provisions the encrypted EFS storage and the services stack runs the Neo4j Fargate service alongside the Studio services.
You do not edit these stacks directly; studioctl manages them. The next pages walk through the prerequisites and the deploy walkthrough.