Skip to main content

migration / Checked 2026-10-18

Move browser download workflows from Kernel to Notte

A migration plan for browser download workflows: retain the business check, replace Kernel's provider-owned resources, and prove the Notte workflow before cutover.

Decide whether this move earns its cost

A signed-in job requests a report from a website and transfers the completed file to application storage. A download beginning is not the delivery outcome.

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 belongs on the shortlist when saved account state and an executable browser workflow simplify the report job. Confirm the chosen file-transfer API and storage boundary in the current docs before moving the delivery step.

A working download-to-storage pipeline is a reason to retain the current provider until an equivalent artifact path is demonstrated. Neither a replay nor a successful page navigation proves that a file arrived.

Keep the result contract stable

A controlled report with a known filename, expected content marker and application-owned destination.

The application receives the complete expected file, verifies its content marker and associates it with the originating account and job.

Preserve the evidence contract across the move: Website report ID, file byte count, content verification and destination object reference.

Map the workflow's resources

RequirementKernelNotte
Code executionTypeScript / Python AppsPython Functions
Scheduled executionApp invocation pathNative
Recordings / replayDocumentedDocumented

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.

  • Separate website report generation from provider file retrieval in the current code.
  • Keep the destination and content check unchanged while replacing the retrieval path.
  • Test delayed and interrupted downloads before switching scheduled report delivery.

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 testRequired observation
Controlled inputA controlled report with a known filename, expected content marker and application-owned destination.
Pass conditionThe application receives the complete expected file, verifies its content marker and associates it with the originating account and job.
Negative caseClose the browser before a deliberately delayed download completes. The job must detect the missing or partial artifact instead of reporting a delivered report.
Evidence to retainWebsite report ID, file byte count, content verification and destination object reference.

A reason to delay or keep the source

Close the browser before a deliberately delayed download completes. The job must detect the missing or partial artifact instead of reporting a delivered report.

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] ↗

Keep comparing

Put the workflow to the test.

Try Notte Read the quickstart ↗