The three-way buying decision
This shortlist starts with Steel and Cloudflare Browser Run, 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 | Steel | Cloudflare Browser Run | Notte |
|---|---|---|---|
| Code execution | External worker | Workers composition | Python Functions |
| Scheduled execution | External scheduler | Workers trigger composition | Native |
| Recordings / replay | Documented | Beta | Documented |
Sources: docs.steel.dev [1] ↗docs.steel.dev [2] ↗developers.cloudflare.com [3] ↗docs.notte.cc [4] ↗docs.notte.cc [5] ↗
Where the code runs
Steel: The reviewed browser documentation establishes sessions, profiles and credentials. It does not establish a hosted Python handler with deployment and invocation APIs. An external worker can control a Steel browser; price and operate that worker separately.
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.
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: docs.steel.dev [1] ↗developers.cloudflare.com [2] ↗docs.notte.cc [3] ↗
Deployment ownership
Steel: Compare managed Steel with the documented self-hosted path explicitly. Self-hosting gives the team infrastructure responsibility that a hosted browser subscription would otherwise cover.
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.
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: docs.steel.dev [1] ↗developers.cloudflare.com [2] ↗docs.notte.cc [3] ↗
Pricing model
Steel: Hosted browser plans and a self-hosted browser have different cost structures. For self-hosting, include the worker, compute, networking, storage and operations rather than assigning the open-source code a zero operating cost.
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.
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: docs.steel.dev [1] ↗developers.cloudflare.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.
Steel: Steel's managed and self-hosted choices make infrastructure ownership a concrete deciding factor. Keep that option on the shortlist when operating the browser is intentional; evaluate Notte when owning fewer execution and authentication components is the actual goal.
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.
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: docs.steel.dev [1] ↗docs.steel.dev [2] ↗docs.steel.dev [3] ↗developers.cloudflare.com [4] ↗developers.cloudflare.com [5] ↗docs.notte.cc [6] ↗docs.notte.cc [7] ↗notte.cc [8] ↗
How to remove an option from the shortlist
For this workflow, require the following evidence from Steel, Cloudflare Browser Run 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: docs.steel.dev [1] ↗developers.cloudflare.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.