What Kernel supplies
Kernel provides cloud browsers and an app platform for TypeScript or Python code. App actions run alongside Kernel browsers, while profiles and Managed Auth handle retained state and sign-in connections.
Your code makes many browser calls and you want to deploy it beside the browser, or you need Kernel's managed sign-in flow.
This is a source-based buying guide, not a claim of hands-on testing across every documented feature. Follow the source for the product and plan you would actually use.
Sources: kernel.sh ↗
Browser control
Kernel: Kernel exposes browser creation and control APIs. Its documentation distinguishes on-demand browsers from configured browser pools, so compare the acquisition path your application will actually use.
Sources: kernel.sh ↗
What survives a session
Kernel: Profiles preserve browser user-data-directory state, including cookies, site data, tabs and preferences. Profile sharing and save behavior need explicit treatment when parallel workers use seeded state.
Sources: kernel.sh ↗
Website login
Kernel: Managed Auth handles website login and eligible connection recovery. Vault fill is a separate flow for applications that control navigation and form submission; the reviewed vault documentation labels that surface as preview.
Sources: kernel.sh ↗
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.
Sources: kernel.sh ↗
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.
Sources: kernel.sh ↗
Capacity and limits
Kernel: Kernel documents concurrent browsers, browser creation rate and per-browser resources separately. Standby browsers can still consume concurrency. Pools change how browsers are acquired; they do not erase account limits.
Sources: kernel.sh ↗
Inspecting a run
Kernel: Live browser URLs support an embedded view and a read-only option. Replays and browser telemetry are separate observability surfaces; app invocation logs add execution context.
Sources: kernel.sh ↗
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.
Sources: kernel.sh ↗
Where Notte is worth evaluating
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 combines cloud browser sessions with deployed Python automations and website authentication tools. You can control the browser over CDP or use Notte's actions, then deploy repeated work as a Function.
Retaining Kernel can be the right outcome when its documented model already fits the application. Compare Notte only against a concrete missing capability, operating responsibility or cost constraint.
Sources: kernel.sh [1] ↗kernel.sh [2] ↗docs.notte.cc [3] ↗docs.notte.cc [4] ↗
Questions to settle before buying
Browser-local code changes the deployment model. Check app action behavior, account limits and persistent-state ownership before moving an external worker into it.
Ask for the exact session, state and execution contract of the proposed account. A published browser observation does not establish feature availability, supported websites or production access.
- Which workload must pass before purchase?
- Who owns the running code, stored browser state and website connection?
- Which browser and handler limits apply to the selected plan?
- What does the invoice include beyond browser usage?
- What would have to be rebuilt to leave this provider?