why we built it this way
most browser infrastructure runs chromium in containers orchestrated by kubernetes, with warm pools to hide slow starts. we pioneered a different approach: running chromium on unikernels, single-purpose vms that carry only what the browser needs. a unikernel carries the browser and nothing else, so there’s little to boot or keep running. running every browser this way has many benefits, including:- lifecycle actions are fast. a browser is created in about 30ms at p50 and 105ms at p99 (benchmarks), so you can create one per task instead of keeping a warm pool alive to hide start-up time.
- code on the vm is safe to hand an agent. every browser is its own vm, isolated at the hypervisor rather than sharing a host kernel with other tenants, so the browser repl, process execution, and root access over ssh stay contained to that session.
- idle browsers go into standby. five seconds after the last client disconnects, a browser enters standby: it keeps its state and stops accruing usage cost until a client reconnects.
open source
we value open source and transparency, so we publish the browser image and the vm runtime behind KERNEL browsers on github. you can read exactly what runs your agent’s browser, run it yourself, or contribute.kernel-images
the chromium images behind KERNEL browsers.
hypeman
the vm runtime we built to run browsers.
cloud-hypervisor
our fork of the cloud hypervisor virtual machine monitor.
get started
see all features
browsers, stealth, proxies, auth, payments, and everything else, each linking to its docs.
quickstart
hand setup to your coding agent with one prompt, or create your first browser yourself.
cookbooks
end-to-end recipes you can clone and run, from computer use fallbacks to agentic payments.