Guide · August 2026 · 6 min read

Deploy Rasa in your own AWS account with the CDK

Rasa runs single-tenant in your own VPC. One cdk deploy stands up the network, an EFA cluster placement group, a control plane, and a data-node template you scale from the console. This walks through what gets created, how to deploy it, every parameter, and the controls the console gives you.

What the stack creates

The CDK app provisions a single-Availability-Zone VPC with one public subnet, because EFA peers must share a subnet and AZ, and a cluster placement group for low latency. A single security group is self-referencing for all traffic inbound and outbound (EFA's SRD transport needs both directions to itself; a plain allow-all egress is not enough), and it opens SSH and the console only to the CIDR you pass.

On top of that network it places a control-plane instance running Valkey, the kv-manager auto-rotation engine, and the kv-console-api server, with the Valkey password generated into Secrets Manager. It also creates a data-node launch template (an EFA network interface, the placement group, and user-data that registers the node against the control plane) and the IAM wiring that lets the control plane launch and retire data nodes on your behalf. Data nodes are not created at deploy time, so you only pay for the capacity you ask for.

Prerequisites

AWS credentials for the target account (aws sts get-caller-identity works).
Node.js 18+ and the AWS CDK (npm i -g aws-cdk).
An EFA-capable instance quota in the region. The default data node is c8gn.16xlarge; the control plane defaults to m7g.xlarge.
Your admin IP, so the console and SSH are not open to the world.

Deploy

Deploying is a one-time CDK bootstrap for the account and region, then a single cdk deploy with your admin CIDR passed in as context so the console and SSH are reachable only from your IP. The CDK app is provided with preview access.

On success the stack prints its outputs: the console URL, the control-plane public and private IPs, the data-node launch-template name, and the Valkey secret ARN.

Parameters

Everything is tuned through CDK context, either on the command line with -c key=value or in cdk.json.

Key	Default	What it controls
`adminCidr`	`0.0.0.0/0`	CIDR allowed to reach SSH and the console. Set this to your IP.
`instanceType`	`c8gn.16xlarge`	Data-node type. Must be EFA-capable.
`cpInstanceType`	`m7g.xlarge`	Control-plane type. No EFA needed.
`amiId`	latest AL2023 arm64	Prebuilt data-node AMI, supplied with preview access.

The adminCidr default is wide on purpose so a first deploy works, but you should always narrow it. If you would rather not expose the console at all, leave it tight and reach the console over an SSH tunnel instead.

Controls in the console

Open the ConsoleUrl output, or tunnel to it with ssh -L 8080:localhost:8080 ec2-user@<cp-ip> and open http://localhost:8080. The dashboard reads a live snapshot from Valkey, so what you see is the real cluster state, not a cached view. It shows cluster membership, each node's health (alive, draining, or dead), its arenas and free slots, a rolling metrics series (utilization and served bandwidth), the active read leases per cache, and a feed of node events such as rotations.

The console can also act on the cluster. The available controls are:

Add data node. The button in the top bar asks the control plane to launch one more node from the launch template. The new instance boots, self-registers, and appears in the dashboard.
Rotate an arena. Reclaim a fully dead arena by rotating its memory region to a fresh remote key, which hardware-fences any stale reader.
Drain a node. Seal a node's active arenas so the allocator stops granting new slots from them ahead of a rotation. The node stays readable while it drains.
Report inventory. Ask a node to re-publish its current arenas and occupancy, a quick way to reconcile the dashboard with the node's own view.

The mutating controls are off unless the console server runs with --allow-commands (the CDK turns it on). Each one is validated as a real node command before it is written to the node's command stream, so the dashboard can only issue operations a node already knows how to execute. To remove capacity, terminate a data node; its heartbeat lease lapses, the manager marks it dead, and its metadata is invalidated, which is lazy and safe.

Teardown

Data nodes you launched from the console are not part of the stack, so terminate them first, then destroy the stack:

# terminate any running data nodes
aws ec2 terminate-instances --instance-ids $(aws ec2 describe-instances \
  --filters Name=tag:rasa:role,Values=data-node Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceId' --output text)

cdk destroy

A note on first deploys

Data nodes launch from a prebuilt AMI, so a new node starts a ready binary rather than preparing one, and comes up in the time it takes the instance to boot and register. Pass the AMI you were issued as -c amiId=ami-.... The stack itself is synthesized and validated; treat your first cdk deploy as the run that shakes out anything specific to your account and region.

Rasa is in private preview. The CDK app, the data-node AMI, and the full parameter reference come with preview access.