Nova Act quick deploy studio

Nova Act quick deploy studio is a self-hostable web application that lets you author, run, and schedule browser automations from a single UI. It deploys into your own AWS account in one click and brings its own website, authentication, agent runtime, and storage — no separate managed service of ours sits in front of it, and no data leaves your account.

Workflows are powered by the Amazon Nova Act AWS service: browser sessions and act steps run there, invoked from the agent container in your account under your account's IAM permissions.

Features

• Author workflows with natural-language instructions and reusable steps.
• Live browser streaming — watch the agent drive a real Chromium session in real time via DCV.
• Scheduling — run any workflow on a cron or rate schedule.
• Run history and traces — full replay of every step, including screenshots and model output.
• Self-contained — everything (website, auth, agent runtime, data) lives in your AWS account.

Architecture

Nova Act quick deploy studio is shipped as a single CloudFormation template. Once deployed, your account contains:

• CloudFront + S3 — private website distribution.
• Cognito — user pool + identity pool for sign-in and API access.
• Bedrock AgentCore — hosted browser and runtime that runs the agent container. The agent in turn drives browser sessions and act steps through the Nova Act AWS service, under your account's IAM permissions.
• Lambda + EventBridge Scheduler — run orchestrator and schedule dispatch.
• DynamoDB — workflow, run, and schedule state. Encrypted at rest with a customer-managed KMS key (rotation enabled). Point-In-Time Recovery is available via the PointInTimeRecoveryEnabled parameter.
• CodeBuild + ECR — builds the agent container image on first deploy. ECR basic image scanning (scan-on-push) is enabled automatically.

Everything is provisioned and updated from the template — there is nothing to manage out-of-band.

Installation

Option 1 — One-click deploy (recommended)

Click the button below to launch Nova Act quick deploy studio into your AWS account. The link opens the CloudFormation quick-create console with the template pre-filled.

Prerequisites:

• An AWS account.
• Region: us-east-1.
• Permission to create the stack's resources (CloudFront, S3, Cognito, Lambda, DynamoDB, IAM, CodeBuild, ECR, Bedrock AgentCore).

On the quick-create page, fill in the parameters:

Parameter	Required	Description
InitialUserEmails	No†	Comma-separated list of up to 5 emails to seed as Cognito users.
PlaygroundChatModelId	No	Bedrock model ID used by the playground chat assistant. Pick from the dropdown. Defaults to us.amazon.nova-pro-v1:0.
PointInTimeRecoveryEnabled	No	Yes / No — enable DynamoDB Point-In-Time Recovery (35-day continuous backup of the app table, at extra cost). Defaults to No.
StackLabel	No	1–6 lowercase alphanumeric chars. Lets you run multiple stacks side-by-side.
VpcSecurityGroupIds	No	Security group IDs. Required when VpcSubnetIds is set.
VpcSubnetIds	No	Private subnet IDs if you want the AgentCore Browser to run inside a VPC.
WebsiteAssetsCdnUrl	Yes	HTTPS URL of the assets CDN that hosts the website bundle and agent container. Pre-filled by the launch-stack link — do not change unless you are self-hosting the assets.

† InitialUserEmails is technically optional, but self-registration is disabled. If you deploy without seeding at least one email, nobody can sign in to the app. You would then have to create users manually via the Cognito console. We strongly recommend providing at least one email here.

After the stack reaches CREATE_COMPLETE (typically 10–15 minutes, most of it spent on the CodeBuild agent image build):

1. Open the ApplicationUrl stack output.
2. Sign in with one of the seeded emails — a temporary password is sent on stack creation.
3. Set a permanent password and start building workflows.

Option 2 — Deploy from source

If you want to customize the stack or run a private build, deploy the template directly.

Note: template.json is larger than 51,200 bytes, which exceeds the inline upload limit for both the CloudFormation console's Upload a template file option and the AWS CLI's --template-body flag. You must first stage the template in S3 and reference it by URL.

WebsiteAssetsCdnUrl required. The template does not bundle the website or agent container — it fetches them at deploy time from the HTTPS URL you pass in. The one-click link (Option 1) pre-fills this for you; for Option 2 you must supply it yourself. Use the same public assets CDN URL (ask the project maintainers for the current value, or point at your own CDN if you are self-hosting the assets).

1. Download template.json from this repository.

2. Export the S3 bucket you want to stage the template in so the rest of the commands can reference it without being edited:

   export TEMPLATE_BUCKET=<your-bucket>

3. Upload the template to that bucket:

   aws s3 cp template.json "s3://$TEMPLATE_BUCKET/template.json"

4. Open the CloudFormation console in us-east-1.

5. Choose Amazon S3 URL and paste the HTTPS URL of the uploaded object (e.g. https://$TEMPLATE_BUCKET.s3.us-east-1.amazonaws.com/template.json), then click Next.

6. Fill in the parameters (including WebsiteAssetsCdnUrl and InitialUserEmails — see the table above) and complete the wizard.

Or deploy from the CLI:

aws cloudformation create-stack \
  --region us-east-1 \
  --stack-name NovaActStudio \
  --template-url "https://$TEMPLATE_BUCKET.s3.us-east-1.amazonaws.com/template.json" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters \
      ParameterKey=WebsiteAssetsCdnUrl,ParameterValue=https://dlkmui12cb1xn.cloudfront.net \
      ParameterKey=InitialUserEmails,ParameterValue=<you@example.com>

Updating a deployed stack

Updates work the same way as initial deploys: you point CloudFormation at a newer template.json and reuse the existing parameter values.

If you deployed with Option 1 (one-click)

You never created your own bucket — the template was served from our hosted assets CDN via a short-lived presigned URL, so there is nothing for you to re-upload. Update from the CloudFormation console:

1. Open the CloudFormation console in us-east-1 and select your stack (default name: NovaActStudio).
2. Click Update → Replace current template → Amazon S3 URL.
3. In another tab, click the Launch Stack button at the top of this README. That opens the quick-create review page for the latest template and embeds a fresh presigned template URL in the page's Amazon S3 template URL field — copy that value and paste it back into the update wizard from step 2. (Don't submit the quick-create page; you only want its URL.)
4. On the parameters page, leave every field set to Use existing value. CloudFormation already has the parameter values you submitted on the initial deploy — you do not need to look them up or re-enter them.

If you'd rather use the CLI, the simplest path is to switch to Option 2 for this one update: grab template.json from this repository, stage it in an S3 bucket you own, then run the update-stack command below. Your stack's existing parameters are still reused via UsePreviousValue=true.

If you deployed with Option 2 (from source)

Upload the newer template.json to the same S3 bucket you staged it in the first time (the $TEMPLATE_BUCKET you created in Option 2 above) and run update-stack with UsePreviousValue=true for every parameter so you don't have to re-enter them:

aws s3 cp template.json "s3://$TEMPLATE_BUCKET/template.json"

aws cloudformation update-stack \
  --region us-east-1 \
  --stack-name NovaActStudio \
  --template-url "https://$TEMPLATE_BUCKET.s3.us-east-1.amazonaws.com/template.json" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters \
      ParameterKey=WebsiteAssetsCdnUrl,UsePreviousValue=true \
      ParameterKey=InitialUserEmails,UsePreviousValue=true \
      ParameterKey=PlaygroundChatModelId,UsePreviousValue=true \
      ParameterKey=PointInTimeRecoveryEnabled,UsePreviousValue=true \
      ParameterKey=StackLabel,UsePreviousValue=true \
      ParameterKey=VpcSubnetIds,UsePreviousValue=true \
      ParameterKey=VpcSecurityGroupIds,UsePreviousValue=true

Or use the console's Replace current template → Amazon S3 URL flow.

CloudFormation preserves the parameter values from your previous deploy, so you never need to look them up — UsePreviousValue=true (CLI) or Use existing value (console) is enough regardless of which install option you used originally.

Changing the playground chat model

PlaygroundChatModelId is the only parameter most users will want to change after the initial deploy. It controls the playground's chat assistant (the drafting helper that turns natural-language prompts into workflow steps) — not the Nova Act agent itself, so changing it does not alter how workflows run in the browser.

You don't need a new template to switch models — reuse the template already deployed on the stack and just update the parameter:

1. Open the CloudFormation console in us-east-1 and select your stack (default name: NovaActStudio).
2. Click Update → Use existing template → Next.
3. On the Parameters page, leave every field on Use existing value except PlaygroundChatModelId — pick the new model ID from the dropdown.
4. Click through the remaining pages and submit the update.

The change is ready in under a minute. Only values from the template's allowed list appear in the dropdown. If the model you want isn't listed, you'll need to modify the template and redeploy via Option 2.

Demo

1. Sign in

Cognito-backed login. Users are seeded via the InitialUserEmails stack parameter and/or managed and created later through Cognito.

2. Create a workflow

Describe the task in natural language and Nova Act quick deploy studio drafts the steps.

3. Run in the Playground

Watch the agent drive a real browser session, live. Every action and screenshot is captured.

4. Inspect a run

Analyze every step of a past run, including model reasoning, screenshots, and page content.

5. Schedule workflows

Run any workflow on a cron or rate schedule, backed by EventBridge Scheduler.

6. Browse workflows and runs

Slack notifications

Get a Slack message when a run finishes. This is a standalone feature — you can wire it up to any workflow after the stack is deployed.

Create the Slack workflow

Follow Slack's guide for building a workflow that starts outside of Slack: Build a workflow: Create a workflow that starts outside of Slack. When defining the webhook trigger's variables, pick the ones you want from the table below. Names must match exactly so Slack can map the payload into your message steps. Any variables you skip are simply ignored.

Available payload fields

These fields are sent with every notification:

Variable	Type	Description
workflowId	Text	ID of the workflow that ran.
workflowName	Text	Human-readable workflow name.
runInvocationId	Text	ID of the specific run. Use this to deep-link back to the run in the studio.
status	Text	Terminal run status (e.g. SUCCEEDED, FAILED, TIMED_OUT).
errorMessage	Text	Error text when the run failed. Empty string otherwise. Truncated at 2,500 characters.
returnValue	Text	Value returned by the workflow script. Empty string if none. Truncated at 2,500 characters.

Attach the webhook to a workflow

Once you have the webhook URL, paste it into the workflow's notification settings in the studio and pick which statuses should trigger it.

CloudFormation quick-create

What you see after clicking the launch-stack button above.

Security model

Nova Act quick deploy studio is designed for single-tenant use — a small, trusted group of users deploying into their own AWS account. Read this section before adding users you do not fully trust.

Signed-in users can execute arbitrary Python in your AWS account

Workflows in Nova Act quick deploy studio are authored as Python scripts. When a workflow runs (from the Playground or the Runs page), the orchestrator Lambda forwards the script, unmodified, to the AgentCore Runtime, where the agent container executes it with Python's built-in exec(). There is no sandbox.

The agent process runs under an IAM role (AgentCoreRole) that holds the permissions needed to drive browser sessions, call Bedrock models, read/write the trace bucket, and invoke the run orchestrator Lambda. Any user who can sign in to the application can run code with those permissions.

Practical implications:

• Treat every signed-in user as if you had granted them the AgentCoreRole directly.
• Do not deploy Nova Act quick deploy studio into an account that holds sensitive data or production workloads that aren't already in scope for those users.
• Be deliberate about InitialUserEmails and about any users you add later through the Cognito console. Self-registration is disabled specifically so the user list stays small and intentional.
• If you need multi-tenant isolation or a hardened execution sandbox, Nova Act quick deploy studio is not the right tool — run each tenant in its own isolated AWS account.

Defense in depth

This is a by-design property of the single-tenant model, but the template applies several defense-in-depth measures:

• The whole application sits behind Cognito — unauthenticated users cannot reach the run path at all.
• CloudFront distributions are fronted by AWS WAF (managed Common Rules, Amazon IP Reputation List, rate-based rules).
• S3 buckets are private with BlockPublicAccess: BLOCK_ALL and enforceSSL; access flows only through CloudFront via OAC.
• The agent container runs in AgentCore's managed, ephemeral runtime — not on long-lived compute in your account.

Reducing blast radius further

If you want to tighten the trust boundary beyond the defaults, consider:

• Keep the user list small. The single strongest control is who can sign in. Audit Cognito users regularly.
• Review AgentCoreRole. After deploy, open the role in IAM and verify its permissions match what your workflows actually need. Remove or scope down anything you don't use.
• Deploy into a dedicated account. Use an AWS account that contains only Nova Act quick deploy studio and the resources its workflows are meant to touch.
• Use a VPC. Set VpcSubnetIds and VpcSecurityGroupIds so the AgentCore Browser runs inside a private subnet with egress you control.

If you discover a security issue with the project itself, please report it privately rather than opening a public issue.

Uninstall

Delete the CloudFormation stack from the console or the CLI:

aws cloudformation delete-stack \
  --region us-east-1 \
  --stack-name NovaActStudio

On delete, the trace bucket and the CloudFront log bucket are retained (DeletionPolicy: RetainExceptOnCreate) so workflow traces and access logs survive the teardown. If you don't need either, delete them manually.

The DynamoDB table has deletion protection enabled, so delete-stack will fail until you turn it off. That's intentional — it prevents an accidental stack delete from wiping your workflow, run, and schedule data. If you really want to delete the table and its KMS key along with the stack, disable protection first:

aws dynamodb update-table \
  --region us-east-1 \
  --table-name <app-table-name> \
  --no-deletion-protection-enabled

(If you enabled Point-In-Time Recovery and want to keep the data, take an on-demand backup with aws dynamodb create-backup before disabling protection.)