Why KERNEL

What Kernel gives you that a Chrome process doesn’t

Kernel runs Chromium as infrastructure: an isolated, GPU-capable browser you create in milliseconds, drive over four protocols, watch live, record, authenticate, and throw away. If your agent or automation needs a real browser and you’d rather not operate a browser fleet, this is what Kernel replaces.

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 you hit	Running it yourself	On Kernel
Start-up latency	Cold container pull plus Chromium launch — seconds per task	P50 30ms browser creation (benchmarks), or zero-wait acquisition from a browser pool
Isolation	One compromised page shares a kernel with everything else on the box	Each browser is a microVM with its own kernel, filesystem, and network egress
Idle cost	You pay for the container while the agent thinks	Standby mode suspends the browser and stops usage charges 5 seconds after the last activity
Bot detection	You maintain the patches, the fingerprints, and a proxy contract	Anti-detection on every browser, plus a managed solver and proxies that aren’t metered
Logins	Credentials end up in your agent’s context or in a secret store you now own	Managed auth logs in, keeps sessions warm, and hands your agent a profile — no credentials in the loop
Debugging a failure	Reproduce it locally and hope	Live view, replays, and telemetry for the session that actually failed
Scaling	Autoscaling group, image pipeline, cleanup jobs, orphan reaper	browsers.create(), or a pool with a fill rate

Why Kernel over another browser API

Three things are structural rather than roadmap.

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 App 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 is a product, not a cookie jar. Managed auth handles the login, MFA prompts, SSO redirects, and background reauthentication, then persists the result as a profile your agent attaches to any browser. Most platforms hand you cookie storage and stop there.

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

One entry per product, each linking to its canonical page.