Skip to main content
Kernel browsers are sandboxed Chromium instances that boot in under 30ms. Your agent creates them on demand, drives them, and tears them down — no infra to provision, no servers to run.

Your first browser

Install the Kernel SDK first:
  • Typescript/Javascript: npm install @onkernel/sdk
  • Python: pip install kernel
  • Go: go get github.com/kernel/kernel-go-sdk
The response includes everything you need to drive the browser: session_id, cdp_ws_url, webdriver_ws_url, and browser_live_view_url. If your environment restricts outbound traffic, add Kernel’s domains and ports to its allowlist.

Pick the right shape

Most of what you’ll tune at creation time falls into four buckets:

Headless vs headful

headful (default) supports live view, replays, and better stealth — ideal for agent workflows on bot-detected sites. headless is lighter (1 gb vs 8 gb), good for simple scraping.

Stealth and proxies

Turn on stealth mode and route through residential, ISP, or datacenter proxies when you’re hitting sites with bot detection.

GPU acceleration

Required for WebGL, video, and canvas-heavy workloads. Trades off standby support.

Profiles and auth

Persist cookies, storage, and authenticated sessions across runs with a profile, or learn how to hand supported login flows off to Kernel with Managed Auth.

On demand or from a pool

browsers.create() boots a browser for you on the spot. It’s the default while you’re building, and it stays the right fit when your configuration changes per user as you scale. A browser pool keeps browsers already booted on one fixed configuration, so acquire hands you one that’s ready to drive. Consider one once you’ve built and scaled your workload and every run uses the same attributes, or when you need to acquire browsers faster than the rate limit on browsers.create() allows. See Scale to decide which fits your workload.
If you’re on an Enterprise plan, speak with your account manager about applicable rate limits for browsers.create() and what’s best for your workloads.

Lifecycle

A browser stays alive as long as something is driving it — a CDP or WebDriver client, a Live View viewer, or an in-flight computer controls request. After five seconds with none of those active, it enters standby — state is preserved, billing stops. Once in standby, after the configurable timeout (60s by default) elapses it’s deleted. We recommend you delete a browser explicitly when you’re done with it:
See Termination & timeouts for the full set of teardown options.

Full example

Putting it together — create a browser, run Playwright code inside it, tear down:

What’s next

Once you have a browser, you need to drive it. Head to Control to see the four primitives Kernel exposes — computer use, playwright execution, CDP, and WebDriver BiDi — and when to reach for each. To carry cookies, site data, tabs, and preferences into later runs, use Browser Profiles. Profiles can resume an agent workflow, maintain one identity per user or account, or give parallel workers the same read-only starting state. When you’re ready to run this in production, Scale covers whether to keep creating browsers on demand or serve your workload from a browser pool, and the architecture patterns for each.