Decide whether this move earns its cost
A recurring job signs in, performs a permitted browser task and records its result without an interactive caller. Overlapping triggers must not create unintended duplicate work.
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.
Notte is a natural candidate when a scheduled Python handler and its browser should share an execution platform. Check schedule behavior and browser duration independently.
Keep an existing scheduler or a provider-native execution language when it already meets the job contract and a Python port would add unnecessary maintenance. A triggered request is not proof of completion.
Keep the result contract stable
A test schedule with an explicit timezone, fixed inputs and a destination that exposes whether the operation ran once.
Each scheduled attempt has a terminal execution record and a verified business result, and the expected browser cleanup occurs.
Preserve the evidence contract across the move: Scheduled time and timezone, execution ID, business result and overlap outcome.
Map the workflow's resources
| Requirement | Kernel | Notte |
|---|---|---|
| Code execution | TypeScript / Python Apps | Python Functions |
| Scheduled execution | App invocation path | Native |
| Recordings / replay | Documented | Documented |
Sources: kernel.sh [1] ↗kernel.sh [2] ↗docs.notte.cc [3] ↗docs.notte.cc [4] ↗
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.
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.notte.cc [2] ↗
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.
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.notte.cc [2] ↗
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.
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: kernel.sh [1] ↗notte.cc [2] ↗
Cut over one responsibility at a time
For this Kernel-to-Notte migration, keep the business assertion outside provider resource management. Source profile, connection, file and execution IDs are not valid target IDs; use a documented transfer path or establish the corresponding resource in Notte.
Retain source job history and a rollback route until the target pilot passes. A migration checklist is not evidence that saved state or runtime behavior is automatically portable.
- Pause the target schedule while replaying a fixed input manually.
- Verify the Python handler's result and browser cleanup before enabling a canary schedule.
- Run only one authoritative production schedule during cutover and preserve source run history.
Sources: kernel.sh [1] ↗docs.notte.cc [2] ↗docs.notte.cc [3] ↗
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 | A test schedule with an explicit timezone, fixed inputs and a destination that exposes whether the operation ran once. |
| Pass condition | Each scheduled attempt has a terminal execution record and a verified business result, and the expected browser cleanup occurs. |
| Negative case | Let one test run outlive the next trigger. Inspect the overlap policy and verify the intended number of website changes. |
| Evidence to retain | Scheduled time and timezone, execution ID, business result and overlap outcome. |
A reason to delay or keep the source
Let one test run outlive the next trigger. Inspect the overlap policy and verify the intended number of website changes.
Kernel: Browser-local code changes the deployment model. Check app action behavior, account limits and persistent-state ownership before moving an external worker into it.
Delay cutover when the target's selected plan, required artifact path or supported website-account flow is not established. Resolve that gap before moving real jobs, even if the rate comparison favors the target.
Sources: kernel.sh [1] ↗notte.cc [2] ↗