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.

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 logged-in sessions across runs with a profile, or hand auth off to Kernel entirely with managed auth.

On demand or from a pool

browsers.create() boots a browser for you on the spot. That’s the right call while you’re building, and for workloads that run occasionally. Once you’re running the same task repeatedly — or more than a handful at a time — create a browser pool instead. A pool holds browsers that are already booted with your configuration applied, so acquire hands you one that’s ready to drive rather than starting one from scratch. Two things get faster: configurations that restart Chromium on creation (custom viewports, extensions, kiosk mode) are already applied, and acquiring from a pool sidesteps the rate limit on browser creation that you’ll otherwise hit at volume.
An acquired browser returns the same fields as one you created directly, so the rest of your code is identical. Idle browsers in a pool aren’t billed — you pay only while a browser is acquired and running — though pool capacity does count against your concurrency limit.

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. When you’re ready to run this in production, the Browser Pools Quickstart shows how to serve your workload from warm, pre-configured browsers instead of creating one per task.