Browser pools are available on the Start-Up and Enterprise plans. Install the Kernel SDK first:
- Typescript/Javascript:
npm install @onkernel/sdk - Python:
pip install kernel - Go:
go get github.com/kernel/kernel-go-sdk
Create the pool
Create the pool once — at deploy time, on service startup, or by hand from the CLI or dashboard. Keep it out of the code path that serves your workload: pools fill at 25% of their size per minute by default, so a pool of 20 takes about four minutes to warm up completely.Acquire, drive, and release a browser
Now do the work.acquire returns a browser immediately if one is available, or waits until one is. The response carries the same fields as an on-demand browser — session_id, cdp_ws_url, browser_live_view_url — so your automation code doesn’t change.
Release the browser when you’re done. Release in a finally block: a browser you don’t release stays acquired until its idle timeout expires, which shrinks the pool everyone else is acquiring from.
acquire gets it. Pass reuse: false to destroy it instead and have the pool warm a replacement — use that when the browser holds state you don’t want the next task to see. See Release a browser.
Check on the pool
available_count tells you how many browsers are ready to be acquired right now, and acquired_count how many are in use.
available_count regularly hits 0, your tasks are queueing behind acquire and the pool needs to be bigger. If it stays above 30–40% of the pool size under normal load, you can shrink the pool and free up concurrency for other work. Target 10–20% available during typical load.
Resize at any time with update; there’s no need to tear the pool down and rebuild it. Added capacity warms up at the pool’s fill rate, so raise the size before a traffic peak rather than during it:
Before you go to production
Three things behave differently from on-demand browsers:- A pool’s
timeout_secondsonly runs while a browser is acquired. Browsers wait in the pool indefinitely; the clock starts when you acquire one and only counts idle time — no CDP connection, no live view, no in-flight computer controls request. A task that runs for 20 minutes with an active CDP connection won’t be killed by a 10-minute timeout. See Timeout behavior. - Updating a pool doesn’t reconfigure browsers that already exist.
updatechanges the configuration used for browsers created after it. Passdiscard_all_idle: trueto rebuild the idle ones too; acquired browsers keep their old configuration even then. See Update a pool. - A profile set on the pool is read-only. Every browser in the pool shares it, so
save_changesdoesn’t apply at the pool level. To give each of your users their own persisted login state, attach the profile after you acquire the browser — see Per-user profiles with pools.
What’s next
Overview
The full pool API — configuration options, profile refresh, flushing, and deletion.
Scale
Architecture patterns for high concurrency, including pools behind a task queue.
Custom Chrome Policies
Apply Chrome enterprise policies — pop-up handling, download behavior, homepages — to every browser in a pool.
FAQ
Sizing, fill rate, reuse semantics, and debugging pooled browsers in production.