Cloudflare Open-Sources Kitesurf — Lightweight CDP Browser Engine for Agents on Workers

On 13 November 2026 Cloudflare open-sourced Kitesurf under Apache 2.0. The repo is at github.com/cloudflare/kitesurf. It is a stateless browser engine written primarily in Rust (compiled to WebAssembly) that runs entirely inside Cloudflare Workers isolates. It parses HTML, applies CSS, executes page JavaScript, and can produce screenshots without shipping a Chromium binary or a browser container. It speaks the Chrome DevTools Protocol, so existing clients (Puppeteer, chrome-remote-interface, MCP servers that already talk CDP) can attach.

That matters for anyone building agent loops that need to look at the web. Full Chromium is still the safe default when you need pixel-perfect layout, complex SPAs, or every Web Platform feature. It is also expensive: each session burns hundreds of megabytes and non-trivial CPU even when the agent is mostly waiting. Kitesurf’s published numbers (median of five runs across a small set of URLs) show 3.1–3.8× less CPU and 4.7–7.0× less memory than a warm Chromium pool for screenshot and HTML-extraction tasks, at the cost of roughly 1.7–1.8× higher wall time. The engine is explicitly not trying to be a human browser; tabs, extensions, and perfect fidelity are out of scope.

Architecture that fits the agent loop

Kitesurf splits into three pieces that map cleanly onto Workers:

• Engine — the only public-facing component. It owns the CDP WebSocket and REST surface and keeps session state.
• PageScript — a long-lived isolate per page (Dynamic Workers) that holds the DOM and runs JavaScript. Built on pieces of Blitz for HTML/DOM/layout and Stylo for CSS.
• PageRenderer — the rendering side.

Because everything is isolate-scoped and the heavy parts are stateless, you can scale by spinning more Workers rather than more OS processes or VMs. Local development is straightforward:

git clone https://github.com/cloudflare/kitesurf.git
cd kitesurf
pnpm install --frozen-lockfile
pnpm run dev

The first build compiles the Rust core; later builds hit the cache. Wrangler then serves a local endpoint (typically 127.0.0.1:8787). You connect a CDP client to the WebSocket at ws://127.0.0.1:8787/devtools/browser. Deploying your own instance to Cloudflare requires the Workers Paid plan because of Dynamic Workers; the README also notes that there is no built-in authentication, so you are responsible for locking it down if you expose it.

WebMCP support (added in the September update) lets sites expose callable tools instead of forcing the agent to reverse-engineer DOM selectors. That reduces the amount of brittle page-scraping logic agents have to carry.

Trade-offs that show up in real agent workloads

• Memory and CPU headroom: if your agent is opening many short-lived pages (search, extract, screenshot, close), the lower footprint lets you run more concurrent sessions on the same budget. For long-lived sessions that stay on complex sites, the gap shrinks and Chromium’s compatibility advantage often wins.
• Latency: wall-clock time is higher. In an agent loop the model is usually the dominant cost, so an extra few hundred milliseconds on the browser side is often acceptable. If you are chaining many tiny navigations, measure it.
• Compatibility surface: Kitesurf already handles TodoMVC variants, Wikipedia, Hacker News, and large parts of the Cloudflare dashboard. Anything that depends on obscure layout, WebGL, or certain service-worker patterns will still need Chromium.
• Isolation model: each page lives in its own isolate. That is good for security and resource accounting; it also means you cannot assume shared process memory or cheap cross-page communication the way you can with a single Chromium process.

Where this intersects local tooling

Most of the interesting agent work still happens on the developer’s machine or inside a controlled environment. A lightweight CDP engine is useful when you want to drive browsing from a local process without pulling in a full browser binary and its sandbox. The same pattern shows up in other low-latency local systems: you separate the capture or rendering path from the model so that the expensive part can be scaled or swapped independently.

On Windows, for example, real-time audio overlays for calls still live or die by the WASAPI capture path and how cleanly you can keep the audio engine callback short. The browser-side equivalent is keeping the page-isolation and rendering path cheap enough that the agent’s reasoning loop is not starved. Kitesurf is one concrete attempt to make that cheaper for the web half of the problem. Local dual-track capture (mic + loopback) plus a small STT model remains the other half when the “page” is actually a live call.

You can run Kitesurf locally today, point an existing CDP or MCP client at it, and decide per workload whether the resource savings outweigh the compatibility gaps. The source is Apache 2.0, so the usual fork-and-adapt path is open.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.