The three-way buying decision
This shortlist starts with Cloudflare Browser Run and AWS AgentCore Browser, then includes Notte as a third implementation path for webhook-triggered browser Functions. An application event causes a browser operation. Delivery can be repeated, while the browser may finish after the original HTTP caller stops waiting.
The event can be delivered more than once. An asynchronous invocation needs a run identifier and completion handling rather than an assumption that the first HTTP response contains the result.
A proposed acceptance case
An application event causes a browser operation. Delivery can be repeated, while the browser may finish after the original HTTP caller stops waiting.
This is an evaluation design, not a claim that this workflow has been executed successfully on every provider.
| Part of the test | Required observation |
|---|---|
| Controlled input | A test event with a stable application event ID and an operation whose resulting object can be counted. |
| Pass condition | The application tracks a terminal run and the intended number of website changes for that event, including after duplicate delivery. |
| Negative case | Send the same event twice and interrupt the first caller. Verify that run tracking and idempotency still describe the intended outcome. |
| Evidence to retain | Event ID, invocation acknowledgement, execution ID, terminal state and resulting website object. |
Documented mechanisms, side by side
These labels describe product mechanisms. The linked source and the acceptance case determine whether a mechanism meets this workflow's requirement.
| Requirement | Cloudflare Browser Run | AWS AgentCore Browser | Notte |
|---|---|---|---|
| Code execution | Workers composition | External AWS compute | Python Functions |
| Scheduled execution | Workers trigger composition | External scheduler | Native |
| Recordings / replay | Beta | Custom browser + S3 | Documented |
Sources: developers.cloudflare.com [1] ↗docs.aws.amazon.com [2] ↗docs.notte.cc [3] ↗docs.notte.cc [4] ↗
Where the code runs
Cloudflare Browser Run: Deploy browser automation within a Cloudflare Worker or connect to Browser Run from an external process over CDP. Workers provide the execution layer; compare their runtime and deployment model separately from browser access.
AWS AgentCore Browser: The Browser Tool supplies the browser environment. An external process or another AWS execution service runs the application code that controls it. Identify that service and its runtime before comparing it with a deployed browser Function.
Notte: Functions deploy Python code with a run() entry point. Invoke them over HTTP or with an SDK, inspect run history, and roll back code by redeploying an earlier version as the latest version.
Sources: developers.cloudflare.com [1] ↗docs.aws.amazon.com [2] ↗docs.notte.cc [3] ↗
Deployment ownership
Cloudflare Browser Run: A Worker-based deployment fits Cloudflare application infrastructure; direct CDP keeps the controller elsewhere. Durable Objects are a composition for stateful browser work rather than a generic persistent browser profile.
AWS AgentCore Browser: Use an AWS-managed Browser Tool or configure a custom browser with recording, networking and an execution role. Keep the controller's deployment separate in the architecture and operational estimate.
Notte: Use a remote browser from your existing process or deploy the browser automation as a Notte Function. These choices put lifecycle, scheduling and monitoring responsibilities in different places.
Sources: developers.cloudflare.com [1] ↗docs.aws.amazon.com [2] ↗docs.notte.cc [3] ↗
Pricing model
Cloudflare Browser Run: Price browser usage and the Worker execution components required by the workload. The Browser Run pricing page, rather than a single browser-hour estimate, defines included allowances and applicable limits.
AWS AgentCore Browser: A complete AWS workflow may include browser use, the controlling compute service, storage and other metered services. Price the selected architecture and region instead of treating a browser benchmark rate as the final invoice.
Notte: The public usage rates are $0.01 per browser-hour, $0.05 per Function-hour and $10 per GB of managed proxy traffic. Paid plans return their price as usage credits. Price the relevant meters and plan eligibility for the workload.
Sources: developers.cloudflare.com [1] ↗aws.amazon.com [2] ↗notte.cc [3] ↗
What should change the choice?
Consider Notte when an HTTP-invoked Python Function can own the browser task and expose its run history. Your application still needs its own event identity and duplicate-delivery policy.
Cloudflare Browser Run: Cloudflare can be an economical architectural choice when Workers and the surrounding scheduling already exist in your application. Notte is worth evaluating when a browser, deployed Python handler and authentication workflow should share a product rather than a Workers composition.
AWS AgentCore Browser: AgentCore Browser's AWS integration can matter more than moving a browser endpoint. Retain AWS identity and observability requirements in the evaluation, and separately account for the code runner and website login before comparing Notte's integrated workflow.
A TypeScript Function, browser-local action or existing external worker may be the better fit when it already integrates with the event system. Moving the browser does not require moving every webhook handler.
Sources: developers.cloudflare.com [1] ↗developers.cloudflare.com [2] ↗docs.aws.amazon.com [3] ↗aws.amazon.com [4] ↗docs.notte.cc [5] ↗docs.notte.cc [6] ↗notte.cc [7] ↗
How to remove an option from the shortlist
For this workflow, require the following evidence from Cloudflare Browser Run, AWS AgentCore Browser and Notte: Event ID, invocation acknowledgement, execution ID, terminal state and resulting website object.
Remove a proposed configuration when its documented mechanism or a controlled pilot cannot meet the pass condition. Keep an undocumented feature as an unresolved question instead of inventing an equivalence. Do not select a provider solely because it appears in this shortlist.
- The application tracks a terminal run and the intended number of website changes for that event, including after duplicate delivery.
- Send the same event twice and interrupt the first caller. Verify that run tracking and idempotency still describe the intended outcome.
Sources: developers.cloudflare.com [1] ↗docs.aws.amazon.com [2] ↗docs.notte.cc [3] ↗
Make a bounded pilot
Send a test event twice, keep a stable job identifier and verify the intended number of website changes and terminal run records.
Use the same authorized account, input and final-state check in each configuration. Treat a missing product contract as an open question; do not turn an undocumented capability into an unsupported claim or a successful test result.
- Preserve the application's event ID when replacing invocation plumbing.
- Invoke the target from a test event and track its terminal result separately from the initial response.
- Route one event partition to the target and keep duplicate handling enabled during cutover.