Move the workflow, not just the WebSocket.

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

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

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.

Sources: docs.browserbase.com ↗

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 ↗

Steel

Compare managed Steel with the documented self-hosted path explicitly. Self-hosting gives the team infrastructure responsibility that a hosted browser subscription would otherwise cover.

Sources: docs.steel.dev ↗

Choose a practical evaluation

Use the deployment that fits the work your team wants to own. Reusing an existing runner can be practical; a hosted Function can reduce operations; self-hosting can meet a specific infrastructure requirement at the cost of operating it.

Moving a browser to another region while leaving the controller in place changes the network path of every action. The advertised browser creation time does not describe those repeated round trips.

• Draw the controller, browser, state store and scheduler as separate components.
• Check the available browser and execution regions independently.
• Identify which provider owns upgrades, capacity and recordings.
• Verify code and stored-state portability before changing providers.
• Include maintenance and on-call work in a self-hosting decision.

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.