The three-way buying decision
This shortlist starts with Kernel and Steel, 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 | Kernel | Steel | Notte |
|---|---|---|---|
| Code execution | TypeScript / Python Apps | External worker | Python Functions |
| Scheduled execution | App invocation path | External scheduler | Native |
| Recordings / replay | Documented | Documented | Documented |
Sources: kernel.sh [1] ↗kernel.sh [2] ↗docs.steel.dev [3] ↗docs.steel.dev [4] ↗docs.notte.cc [5] ↗docs.notte.cc [6] ↗
Where the code runs
Kernel: Deploy a TypeScript or Python App and expose Actions that callers invoke. Kernel co-locates code with the browser environments the app creates. An Action invocation is the execution unit rather than a bare CDP connection.
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.
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: kernel.sh [1] ↗docs.steel.dev [2] ↗docs.notte.cc [3] ↗
Deployment ownership
Kernel: Kernel Apps move the automation process next to the browser. Alternatively, an external process can control a browser through the browser API. Choose based on execution locality and 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.
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: kernel.sh [1] ↗docs.steel.dev [2] ↗docs.notte.cc [3] ↗
Pricing model
Kernel: Use the plan and browser configuration in Kernel's pricing documentation. Managed networking, account allowances and app execution make a browser-hour comparison only one part of the decision.
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.
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.
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.
Kernel: Kernel's browser-local Apps make execution placement part of the decision. Compare the repeated action path with the proposed Notte controller or Function deployment before concluding that a lifecycle or hourly-rate difference decides the workflow.
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.
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: kernel.sh [1] ↗kernel.sh [2] ↗kernel.sh [3] ↗docs.steel.dev [4] ↗docs.steel.dev [5] ↗docs.steel.dev [6] ↗docs.notte.cc [7] ↗docs.notte.cc [8] ↗notte.cc [9] ↗
How to remove an option from the shortlist
For this workflow, require the following evidence from Kernel, Steel 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: kernel.sh [1] ↗docs.steel.dev [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.