Summary: Cloudflare has released Kitesurf, its stateless browser for AI agents, as open source on GitHub under the Apache 2.0 license. The engine runs entirely on Cloudflare Workers — it parses HTML, applies CSS, executes page JavaScript, and renders screenshots without a browser container. If your agents drive headless Chromium today, you can now read this code, fork it, run it on localhost, and deploy your own instance to your own account.
What a browser without a container means
Cloudflare introduced Kitesurf in August and followed up in September with WebMCP support, new APIs, and improved compatibility. The stated goal throughout: give agents a lightweight browser that loads sites, runs JavaScript, and interacts with pages while using less CPU and memory than a full browser like Chromium, scaling on demand across Cloudflare’s global Workers network.
The practical hook for builders is compatibility with the Chrome DevTools Protocol (CDP). You can connect existing clients such as Puppeteer, or point an agent harness straight at the local CDP port. That means adoption does not require rewriting your tooling — the parts of your stack that already speak CDP keep working.
Under the hood: Rust compiled to WebAssembly
Kitesurf is not a wrapper around Chromium. It is an independent browser engine built on open-source Rust packages compiled to WebAssembly:
- Blitz handles HTML parsing, the DOM, layout, and painting.
- Stylo handles CSS parsing, cascading, and computed styles.
- Boa runs page JavaScript inside WebAssembly — but only as a last resort, when JavaScript cannot run in Dynamic Workers instead.
- Linebender libraries provide text layout and 2D graphics, and Krilla generates PDF output.
The repository splits into three main parts: the Engine manages browser sessions and client connections, PageScript runs the page and its JavaScript, and PageRenderer draws the result. Cloudflare is explicit that Kitesurf is under heavy development, with compatibility — tracked through its Web Platform Test evolution — reliability, and efficiency all still being worked on.
Running it yourself, and what it costs
The local path is free: clone the repo, install dependencies, and run the dev command — wrangler starts a local server at http://127.0.0.1:8787. The first build compiles the Rust core, so expect it to take a while; later builds reuse the cache. From there you can drive it with Puppeteer:
import puppeteer from "puppeteer-core";
const browser = await puppeteer.connect({
browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser",
});
try {
const page = await browser.newPage();
await page.goto("https://example.com/");
await page.screenshot({ path: "page.png" });
} finally {
await browser.disconnect();
}Deploying to your own Cloudflare account — instead of using the managed Browser Run APIs — requires a Workers Paid plan, because Kitesurf uses Dynamic Workers to spin up isolated Workers per page. That is the real minimum spend on the self-host path. Contributions are welcome but gated: you need to be vouched by a maintainer before opening a pull request, and focused fixes with tests are easier to land than large rewrites.
Our take: Try it now, as an experiment — not as a migration. Running it locally costs nothing and is fully reversible: clone the repo, point one real agent workflow at the CDP port, and see whether the task completes. That is exactly the kind of cheap, undoable test worth an afternoon. It matters most for small teams running browser-using agents on headless Chromium, where container CPU and memory are a per-session cost with no platform engineers to tune them. Two caveats. The deploy path has a hard floor in the Workers Paid plan, so price that before committing. And Cloudflare’s less-CPU-and-memory claim is a stated goal, not a measured result — the post includes no numbers showing the savings in practice, so treat it as a hypothesis your own run either supports or kills. If your target sites fail to render or execute their JavaScript, the efficiency argument collapses and you should stay on your current browser. If your agents never browse, or your browser infrastructure is already settled, you can safely ignore this. We would call it production-ready only after your real task completes reliably on it.