Why not just run Chrome yourself?
You can. Running one Chrome locally is easy, and it’s the right call while you’re prototyping. The work starts when the automation has to run unattended, more than once, at more than one at a time.What’s structural about Kernel
MicroVM isolation, not containers. Every browser gets its own kernel via unikernel-based virtualization. That’s what makes both the isolation story and the 30ms start possible at the same time, and it’s why file I/O, shell access, and GPU access are available inside a session at all. Your loop can run next to the browser. The Playwright execution API runs your code inside the browser’s VM, and the code execution platform deploys your whole agent there. No round trip per action, no CDP connection to babysit, and no CDP fingerprint on the wire. See how you drive the browser for how to choose. Auth and payments are built on primitives. Vaults hold credentials and payment items that a browser fills into a page without your agent ever reading them. Profiles persist cookies, storage, and logins across sessions. Authentication builds on both: fill a login from a vault, or let managed auth handle the login, MFA prompts, SSO redirects, and background reauthentication, then save the result as a profile your agent attaches to any browser. Payments use the same vaults, so an agent can complete a checkout through Link or AgentCard without seeing card data.When Kernel isn’t the answer
If the site you need has a real API, use the API. Browsers are the right tool when the work only exists behind a UI — a portal with no API, a checkout flow, a document you can only reach after logging in, or a task that a computer-use model has to see to do.See all products
Every product, each linking to its documentation.