Skip to main content
A browser pool keeps a set of identically-configured browsers warm and ready to use. Acquiring a browser from a pool is faster than creating one on demand because the browser has already booted with your stealth, proxy, extension, viewport, and profile settings applied. Idle browsers in a pool aren’t billed. You pay the standard per-second rate only while a browser is acquired and running, so a warm pool costs nothing between tasks. Pool capacity does count against your concurrency limit — a pool of 20 uses 20 of your limit whether or not those browsers are acquired.
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.
Every browser in the pool gets the same configuration, so put whatever your workload needs here — proxies, extensions, a viewport, a profile, custom Chrome policies. See Pool configuration options for the full list.

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.
By default, released browsers are reused: the browser goes back into the pool as-is and the next 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.
Watch this number to size the pool. If 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_seconds only 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. update changes the configuration used for browsers created after it. Pass discard_all_idle: true to 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_changes doesn’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.