nova-act-quick-deploy
# 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](https://labs.amazon.science/blog/nova-act): 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. [](https://d2yndxx8ib1670.cloudfront.net) 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`](./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: ```bash export TEMPLATE_BUCKET=<your-bucket> ``` 3. Upload the template to that bucket: ```bash aws s3 cp template.json "s3://$TEMPLATE_BUCKET/template.json" ``` 4. Open the [CloudFormation console](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/create) 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: ```bash 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=<[email protected]> ``` ### 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](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks) 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: ```bash 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](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks) 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](https://slack.com/help/articles/360041352714-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: ```bash 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: ```bash 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.)