nova-act-quick-deploy

KO | EN

gitlite — search

#react #ai #llm #golang #android #rust #nodejs #windows #awesome-list #vue #security #ios #openai #open-source

nova-act-quick-deploy

(★ 12)

Nova Act quick deploy studio is a self-hostable web application that lets you author, run, and schedule browser automations from a single UI.

nova-act-quick-deploy 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# 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.

![Nova Act quick deploy studio — Playground](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/playground.png)
![Nova Act quick deploy studio — Playground](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/playground-light.png)

## 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.

[![Launch Stack](https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png)](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=<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](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.

![Login](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/login.png)
![Login](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/login-light.png)

### 2. Create a workflow

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

![Create workflow](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/create-workflow.png)
![Create workflow](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/create-workflow-light.png)

### 3. Run in the Playground

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

![Playground](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/playground.png)
![Playground](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/playground-light.png)

### 4. Inspect a run

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

![Run details](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/run-details.png)
![Run details](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/run-details-light.png)

### 5. Schedule workflows

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

![Schedules](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/schedules.png)
![Schedules](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/schedules-light.png)

### 6. Browse workflows and runs

![Workflows list](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/workflows-list.png)
![Workflows list](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/workflows-list-light.png)

![Runs list](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/runs-list.png)
![Runs list](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/runs-list-light.png)

## 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.

![Quick-create console](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/quick-create.png)
![Quick-create console](https://raw.githubusercontent.com/amazon-agi-labs/nova-act-quick-deploy/main/screenshots/quick-create-light.png)

## 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.)

nova-act-quick-deploy

nova-act-quick-deploy 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

nova-act-quick-deploy

nova-act-quick-deploy 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README