Who should own capacity, upgrades and browser artifacts?
Start with the parts your team already operates. Hosting the browser yourself can meet a specific infrastructure requirement, but it also puts browser process health, storage and capacity on your team.
Managed browser access removes one infrastructure responsibility. Your team may still own the code runner, state store, scheduler and artifacts. A self-hosted engine moves more of that responsibility back into your environment.
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 ↗
Anchor Browser
Use a browser session from existing code or deploy a reusable Automation Task. The task path includes workflow editing and versioning; direct CDP leaves execution ownership with your application.
Sources: docs.anchorbrowser.io ↗
Evaluate the operational difference
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.
Make the acceptance test explicit
Describe the work that must finish, the account it runs under, the state it needs to retain and the expected output. Select eligible product configurations before measuring latency or price.
Run the same workflow with each proposed architecture. Keep startup measurements separate from task execution, and distinguish provider failure from a configuration error or an unsupported website action.
Choose the responsibility you want to own
An external runner keeps deployment and queues in your application. A hosted execution layer moves part of that responsibility to the browser platform. Saved browser state reduces repeated setup, while managed website authentication may add readiness checks. Choose each part deliberately rather than treating a brand as one indivisible feature list.