Your browser code needs somewhere to run.

What the comparison covers

Sessions cover browser control, lifecycle, state, live view, recording and capacity. Functions cover where browser code runs and how it is deployed, invoked, scheduled and monitored. Auth covers website account state, credential handling and connection readiness.

Each provider's product surfaces stay separate. A hosted agent is not a deployed Function, an API key is not a website login, and a persisted profile is not a guarantee of authentication. The directory links focused comparisons when those differences determine the choice.

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: docs.notte.cc ↗

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.

Sources: docs.browserbase.com ↗

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 ↗

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.

Sources: docs.steel.dev ↗

Choose a practical evaluation

Keep an external runner when you already operate one and need portability. A native execution layer can remove deployment work; browser-local code can reduce repeated network calls. Compare actual workload behavior before assuming either always wins.

A scheduled job should return a verified result and stop its owned browser even when an action fails. The scheduler's successful HTTP trigger is not proof that the browser completed the business operation.

• Confirm the supported language, entry point and dependency packaging.
• Trace deployment, version selection, invocation and cancellation.
• Keep the handler runtime limit separate from browser session duration.
• Decide whether scheduling is native or supplied by another service.
• Associate results and logs with both the code version and browser session.

From a comparison to a working workflow

Start with a short browser task and a pass/fail result. Add the necessary account state, then exercise the production shape: concurrency, duration, triggers and retained artifacts. Keep the provider's documented cleanup flow in place from the first test.

The full directory includes provider comparisons, focused buying questions, workload shortlists, competitor buying guides and migrations to Notte. Use it to resolve a specific implementation decision rather than assuming the most feature-rich or fastest-starting product will fit every job.