The job and its deciding constraint
A team releases a browser automation change, discovers a regression and needs to restore a known implementation while retaining the history of affected runs.
Providers differ on whether invocation selects a version or always runs the latest code. Rolling back can create a new latest deployment rather than changing an old run.
A proposed acceptance case
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 | Two harmless code versions that return different markers and a recorded invocation for each version. |
| Pass condition | New runs execute the intended implementation after rollback, while historical runs remain associated with the implementation that actually ran. |
| Negative case | Invoke after changing the latest deployment and check whether the caller runs a pinned or latest version. The application must not infer the executed version from a filename. |
| Evidence to retain | Deployed implementation marker, invocation configuration, historical run version and rollback result. |
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 | Notte | Browserbase | Kernel |
|---|---|---|---|
| Code execution | Python Functions | TypeScript Functions | TypeScript / Python Apps |
| Scheduled execution | Native | External trigger path | App invocation path |
| Recordings / replay | Documented | Documented | Documented |
Sources: docs.notte.cc [1] ↗docs.notte.cc [2] ↗docs.browserbase.com [3] ↗docs.browserbase.com [4] ↗kernel.sh [5] ↗kernel.sh [6] ↗
Deployment ownership
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.
Browserbase: Publish TypeScript Functions through the supported deployment flow. The reviewed Function overview lists us-west-2 availability; this is narrower than assuming every browser region also hosts Functions.
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.
Sources: docs.notte.cc [1] ↗docs.browserbase.com [2] ↗kernel.sh [3] ↗
Where the code runs
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.
Browserbase: A Function is TypeScript code published with an entry point. Invocation starts asynchronously, creates a browser, passes its connection URL to the handler, and stores the result, logs and session ID. Function webhooks report status changes.
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.
Sources: docs.notte.cc [1] ↗docs.browserbase.com [2] ↗kernel.sh [3] ↗
Pricing model
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.
Browserbase: Compare the public plan's included browser allowance and overage with the workflow's duration. Include proxy traffic and any separately priced services; an Arena browser-hour estimate does not describe the whole Browserbase bill.
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.
What should change the choice?
Notte's Python deployment and run-history layer is relevant when release management belongs with browser execution. Its documented rollback approach redeploys an earlier implementation as the latest version.
Browserbase: Browserbase's TypeScript Function contract is a reason to retain it when that is the deployed language your team wants. A move to Notte Functions includes a Python execution decision; moving only the browser can leave your existing controller in place.
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.
Retain another execution platform when its language, dependency packaging or version-selection contract is essential to the application. Similar version numbers do not establish the same invocation semantics.
Sources: docs.notte.cc [1] ↗docs.notte.cc [2] ↗notte.cc [3] ↗docs.browserbase.com [4] ↗browserbase.com [5] ↗kernel.sh [6] ↗kernel.sh [7] ↗kernel.sh [8] ↗
Make a bounded pilot
Deploy two safe versions, record the executed version with each result, and verify rollback using the documented version-selection behavior.
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.
- Save the source implementation and the version behavior callers rely on.
- Deploy two target implementations with visible markers and record which one runs.
- Rehearse restoring the earlier implementation before routing production invocations.