Cloudflare Launches Kitesurf, an Agent-First Browser Built on Workers and V8 Isolates

Cloudflare Launches Kitesurf, an Agent-First Browser Built on Workers and V8 Isolates Cloudflare has introduced Kitesurf, a lightweight headless browser engineered specifically for AI agent workloads and deployed on V8 isolates via Cloudflare Workers. Built as an alternative to resource-heavy Chromium instances, Kitesurf aims to significantly reduce CPU and memory overhead during automated tasks like scraping, screenshot generation, and content extraction. Kitesurf runs entirely on Cloudflare Workers and is designed specifically for automated AI agents rather than human-facing web browsing. Across a 14-URL benchmark corpus, Kitesurf uses 3 to 7 times less CPU and memory than Chromium, though Chromium remains about 1.7 times faster due to JIT and software rasterization differences. The architecture splits operations across isolated Workers: an Engine handling Chrome DevTools Protocol (CDP), a PageScript component using Blitz and Stylo, a PageRenderer for rasterization, and a SandboxOutbound worker enforcing network safety. Because Workers lack native eval support, Kitesurf embeds Boa JS, an ECMAScript engine compiled to WebAssembly, to execute occasional eval operations. The browser currently passes over 215,000 Web Platform Tests, is available free in beta through Browser Run, and is planned for an eventual open-source release. Motivation and Agent-Specific Design Cloudflare identified that existing browser engines like Chromium carry significant compute and memory overhead tailored for human interaction, making per-agent instances costly at scale. Kitesurf was conceptualized to prioritize attributes critical to AI agents—such as rapid startup, lower resource footprint, and isolated execution—while omitting human-centric conveniences. The project draws initial inspiration from obscura, a minimalist headless Rust engine, and was rapidly developed over 12 weeks with the aid of AI agents driven by extensive automated testing. Core Multi-Isolate Architecture The browser architecture relies on Cloudflare Workers primitives, including Dynamic Workers and built-in JavaScript RPC. External interaction is managed by the Engine worker via the Chrome DevTools Protocol (CDP), maintaining backwards compatibility with Puppeteer, Playwright, and MCP clients. Untrusted network requests are strictly isolated to the SandboxOutbound worker, which enforces CORS, applies headers, and manages per-page cookie jars. For each page or iframe, Dynamic Workers launch an isolated PageScript worker that utilizes modular Rust packages compiled via wasm-bindgen, including parts of Blitz for HTML parsing and Servo's Stylo for CSS. To handle unsupported eval calls within Workers, Kitesurf runs the Boa JS engine on top of the runtime. Rendering Pipeline and Fault Isolation Visual outputs are generated by the stateless PageRenderer worker, which receives the scene from PageScript, fetches font and image assets, and rasterizes frames using blitz-paint and Parley. Communication between workers takes place through native Worker RPC. Because PageRenderer retains no state beyond a throwaway cache, failing or hanging render requests can be dropped and restarted cleanly. The system enforces an overarching resilience model where failures degrade to empty elements or blank frames instead of terminating entire sessions. Performance Benchmarks, Current Limits, and Availability Benchmark medians on a 14-URL corpus show that while Chromium completes tasks approximately 1.7 times faster due to JIT compilation, Kitesurf achieves a 3- to 7-fold reduction in CPU and memory consumption. It currently passes more than 215,000 Web Platform Tests and renders complex sites such as Wikipedia, Hacker News, TodoMVC variants, and Cloudflare internal interfaces. However, it is not yet suitable for tasks requiring persistent session state, video playback, WebGL, or complex TLS fingerprinting for bot-challenge handshakes. Kitesurf is currently available in beta via Cloudflare Browser Run and a public playground, with plans for an open-source release.

Cloudflare 发布面向 AI Agent 的新型浏览器 Kitesurf，完全基于 Workers 与 V8 隔离区运行 Cloudflare 宣布推出针对 AI Agent 场景打造的新型无头浏览器 Kitesurf。该项目直接运行在 Cloudflare Workers 平台之上，通过轻量级无状态架构和 Rust/Wasm 编译，相比 Chromium 降低了 3 至 7 倍的 CPU 与内存消耗，目前已在 Browser Run 开启免费公测。 针对 Chromium 在 Agent 自动化场景中内存和算力开销过大的问题，Cloudflare 耗时 12 周研发了 Kitesurf。 架构由 Engine、PageScript 和 PageRenderer 三大组件组成，网络请求完全经由 SandboxOutbound Worker 隔离沙盒处理。 底层采用 Rust 原生编译至 Wasm（利用 Blitz、Stylo 和 Boa JS），结合 Workers 的 Dynamic Workers 与内置 RPC 系统实现跨隔离区通信。 在性能测试中，Chromium 因 JIT 与光栅化在执行耗时上快约 1.7 倍，但 Kitesurf 的内存和 CPU 占用降低了 3 到 7 倍。 兼容 Chrome DevTools Protocol (CDP)，支持 Puppeteer、Playwright 等工具，未来计划完全开源。 研发背景与核心理念 传统浏览器引擎（如 Chromium）专为人类交互设计，带有大量 AI 模型并不需要的开销，高昂的资源占用限制了大规模 Agent 应用的普及。Cloudflare 借助在 Workers 平台上的 Wasm 支持、Dynamic Workers、RPC 等基础设施演进，确立了以测试驱动、尽可能使用原生 Rust 编译 Wasm、全面容错降级、严格隔离与无状态化为核心的设计原则，旨在为突发、高并发的 Agent 任务提供轻量、低成本的浏览器环境。 技术架构与组件拆分 Kitesurf 的请求链路分为三大组件：Engine Worker 是唯一的公开接入点，负责维护会话状态并提供 CDP 接口以兼容 Puppeteer 和 Playwright；PageScript 基于 Dynamic Workers 为每个页面或跨源 iframe 启动隔离区，利用 Rust 编写的 Blitz 和 Stylo 解析 HTML 与 CSS，并借助 Boa JS 运行时处理 eval；PageRenderer 采用无状态设计，通过 blitz-paint 与 Parley 将场景光栅化为图像并经由 RPC 返回。所有外部网络请求则统一收敛至 SandboxOutbound Worker 实施严格的内容过滤与 CORS 控制。 性能表现与兼容性测试 项目依赖 AI 协助开发并引入 WPT（已通过超 21.5 万项测试）与视觉回归测试以确保质量。在基准测试中，由于冷启动软件渲染和光栅化开销，Chromium 的端到端耗时比 Kitesurf 快约 1.7 倍；但 Kitesurf 换取了显著的资源优势，CPU 与内存消耗仅为 Chromium 的三分之一至七分之一，大幅削减了运行账单。 适用场景与未来规划 Kitesurf 目前适用于单次快速截图、PDF 生成和文本/HTML 提取等无状态突发任务，已能稳定渲染 TodoMVC、维基百科及 Cloudflare 仪表盘等页面。对于需要运行 WebGL、播放视频、长会话保活或对抗复杂机器人指纹验证的场景，官方仍建议选用 Chromium。Cloudflare 现已提供公开 Playground 和测试接口，并计划在后续完善后将 Kitesurf 完全开源。

Should we build our own browser? This is one of those questions that has come up every few months internally at Cloudflare for years. Unsurprisingly, it’s the kind that triggers long threads with multiple reasons and persuasive arguments on why we should do it. The browser is obviously the most important software we use every day on our computers; it’s arguably the operating system of the Internet. We’re a company on a mission to help build a better Internet — who wouldn’t want to take on the challenge of building a new browser? But we never quite found the balance between the technical difficulty of such an endeavour and the unique problems we’d be solving by doing it. And so, the idea was shelved, over and over again. Until now. Something magical happened: we reached a tipping point where a series of powerful technical advancements in our [Developer Platform](https://developers.cloudflare.com/) became a reality, while the advent of AI agents and the demand for a new kind of browser became critical at the same time. Running [WebAssembly (Wasm)](https://developers.cloudflare.com/workers/runtime-apis/webassembly/) in Workers is now very mature. Primitives like [dynamic workers](https://developers.cloudflare.com/dynamic-workers/), [SQLite-based Durable Objects](https://developers.cloudflare.com/durable-objects/api/sqlite-storage-api/), [Worker-to-worker RPC](https://developers.cloudflare.com/workers/runtime-apis/rpc/), [service bindings](https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/), higher [NodeJS compatibility](https://developers.cloudflare.com/workers/runtime-apis/nodejs/) and higher [limits](https://developers.cloudflare.com/workers/platform/limits/) open doors to much more ambitious and complex applications that were simply not possible before. [Browser Run](https://developers.cloudflare.com/browser-run/), our headless browser automation API product, has seen tremendous growth with the rise of AI. Agents need browsers in order to perform many tasks, and in many cases cannot succeed without them. But there's a problem — browser engines like Chromium were built for humans, not agents, and they come with overhead that AI models simply do not need. They consume so much memory and compute that providing every agent with its own instance is prohibitively expensive, restricting large parts of the Web to only the most sophisticated and costly AI models with higher parametric knowledge, while locking out many other agentic applications. We should be giving *all* agents a browser that excels at what’s important for an AI model, even if that means being light on what’s only useful for humans. For example: Faced with these realizations, 12 weeks ago we asked the question again: Should we build our own browser? This time the answer was unanimous: **Yes!** Today we are announcing **Kitesurf**, a new browser that runs **entirely on top of Workers** that we built specifically for agents, available for free while in beta in [Browser Run](https://developers.cloudflare.com/browser-run/). Kitesurf is significantly more efficient in CPU and memory consumption than Chromium for common agentic tasks like screenshots and HTML extraction. What follows is the story of how we built it. Buckle up, it’s going to get technical — but we promise to keep it interesting. Kitesurf started as many other great ideas have started at Cloudflare. Someone found something interesting, and the next thing you know they end up “nerd sniping” the rest of the team with a seemingly impossible but very attractive idea. We got the initial inspiration from [obscura](https://github.com/h4ckf0r0day/obscura), a headless engine written in Rust for AI automation that has “no Chrome, no Node.js, no dependencies.” Then, with the help of an AI agent, we tried to port it to Workers. It didn't work very well at first. But once we gave the AI a solid plan and a clear definition of success — detailed enough for the agent to loop endlessly and ask questions when needed — it did work. Blown away by this (barely) working proof of concept, we decided to let the team cook. Here are some of the design decisions we made before we started. **Tests, tests, tests** We knew that moving from a prototype to a full-blown browser that could actually be useful for tasks at scale in production would take a lot of work and iteration. We won’t hide that using AI to accelerate the process was key. But how do you use AI in such a complex project, keeping the quality of both code and results under control without losing velocity? The answer is to provide as many tests as you can. Enter the [Web Platform Tests](https://github.com/web-platform-tests/wpt) (WPT), the ideal setup: an extensive suite of success criteria that gave the AI agents clear goalposts for assessing feature conformance. We curated the selection and order of features to assign to the agents, allowing humans to focus on architectural work and reviewing the agents' approaches. However, WPT tests only go so far: they measure conformance to [W3C](https://www.w3.org/) standards, not a browser's ability to render and interact with real-world websites. To bridge this gap, we implemented a combination of integration testing and visual regression testing — it runs multistep [Puppeteer](https://pptr.dev/) tests on real websites against both Chromium and Kitesurf not only by comparing the assertions that it makes, but also rendering outputs at every step to highlight any unwanted differences. **Use Rust when possible** Cloudflare has been working on providing great support for [WebAssembly (Wasm)](https://developers.cloudflare.com/workers/runtime-apis/webassembly/) in Workers for quite some time. This is great because we can use high-performance C, C++, and Rust packages and compile them to Wasm. If we use Emscripten (for example) and its many layers of mocked dependencies, the compiled binary can get bulky and slow. Instead, we opted for native Rust whenever possible and to compile directly to WebAssembly using [wasm-bindgen](https://developers.cloudflare.com/workers/languages/rust/#javascript-plumbing-wasm-bindgen), thus avoiding unnecessary emulation layers and running as close to the metal as possible, [reliably](https://blog.cloudflare.com/making-rust-workers-reliable/). **Exception handling** A browser must render the whole unreliable and sometimes hostile web without ever dropping the page it's holding, so exception handling is more than just hygiene — it's how the application survives bad input without just crashing outright. So we committed to one rule up front: any failure degrades to a blank frame or a missing element, never a dead session. Catch faults at every boundary, default to something safe and empty, and log enough to diagnose. **Isolation** Contrary to running a browser on your laptop (where you're visiting sites you trust, and it's acceptable to share some resources between them), an agent is pointed at whatever a task demands: arbitrary code from arbitrary origins. So we built this browser on the assumption that every page load is untrusted input and every session starts fresh. Each component is isolated and has access only to the resources strictly necessary for its function. This seems like a perfect fit for Cloudflare Workers, whose [security model](https://developers.cloudflare.com/workers/reference/security-model/#isolation) is built around isolation by design. But the platform only gets us the boundary between isolates. We still have to enforce the same principle at the application level, deciding what each component is allowed to touch and making sure nothing leaks across a page it shouldn't. **Stateless whenever possible** State is what makes failure expensive — if there's nothing to reconstruct, recovering from a crash is just starting a new one and replaying the request. A stateless component is disposable and parallel by nature: kill it the moment it stalls, run a thousand at once, and size them to demand instead of keeping things warm. That fits automation perfectly, where load arrives in bursts and the cheapest thing you can do is spin up work that costs only what it used and vanishes when it's done. In short, **wherever a component can be stateless, it should be**. Armed with a good plan, extensive tests, and a good tooling environment, we were ready to get started beyond the initial proof of concept. This is Kitesurf’s very high level life of a request that still holds today: Let’s dive into the three main components that make Kitesurf work: the Engine, PageScript, and PageRenderer. In order to render an untrusted web page, a browser has to fetch arbitrary assets — images, fonts, CSS, JavaScript, and Wasm files — off the Internet. This is one of the most dangerous operations a browser can do. Kitesurf does it through one single component, the SandboxOutbound worker, and nothing else can touch the network directly — enforced by Dynamic Workers. The Engine uses it to bootstrap the page, fetching the main document and its scripts, and PageScript fetches everything else: stylesheets, images, fonts, and the page's own fetch() calls. We use SandboxOutbound to enforce [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS), inject browser-shaped headers, filter responses, and keep each page's cookies in their own jar. Anything that fails our policy gets a 403 — each component gets precisely the network it needs and nothing more. The Engine is the only public-facing component of Kitesurf. It handles the Chrome DevTools Protocol (CDP) WebSocket and HTTP REST APIs, serves a landing page that is useful for internal testing purposes and, most importantly, stores each session state. All other components are stateless. The advantage of using CDP is client compatibility: [Puppeteer](https://developers.cloudflare.com/browser-run/puppeteer/), Playwright, chrome-remote-interface, and the actual Chrome DevTools frontend. Point them at Kitesurf and they will all just work. This is also how Browser Run [works](https://developers.cloudflare.com/browser-run/cdp/) (more on why this is important later). Contrary to what the name suggests, the Engine is actually the simplest of the Kitesurf components. The fun parts come next. PageScript offers a good example of the power of our new Workers features: in this case, [Dynamic Workers](https://developers.cloudflare.com/dynamic-workers/).  Kitesurf simply wouldn’t have been possible before this. Here’s a simplified diagram of how PageScript works internally. Every next page or out-of-process iframe ([OOPIF](https://www.chromium.org/developers/design-documents/oop-iframes/)) uses Dynamic Workers to spin up a long-lived PageScript isolate that handles the page session, consisting of a clean [globalThis](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis) and the [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) document object. The DOM object is then populated with the results of parsing the HTML document and running all the JavaScript scripts. For parsing the HTML and the CSS we use parts of [Blitz](https://github.com/DioxusLabs/blitz), a modular rendering engine, and [Stylo](https://github.com/servo/stylo), Firefox’s high-performance CSS parser, both written in Rust. For each found \<script> tag or .wasm file we run the JavaScript and WebAssembly code inside the same isolate. **Yes, but evals** What about [evals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval), you ask? Evals are trickier to handle because for [security reasons](https://developers.cloudflare.com/workers/runtime-apis/web-standards/#javascript-standards) we still don’t support eval natively in Workers. We can’t spin another isolate to handle them either, because it wouldn’t have access to globalThis. Our solution is to use [Boa JS](https://boajs.dev/), an ECMAScript engine written in Rust, to compile and run on Workers. We are basically executing a runtime on top of a runtime, which doesn’t seem optimal, and it isn’t, but it works well enough to handle the occasional evals we find in the code. In the future, when native eval support lands in Workers, we will migrate away from Boa. This component is essentially responsible for generating the actual pixels from the computed page objects. Here’s how it works: PageRenderer works in a loop with the Engine Worker. Every time the engine needs a frame, PageRenderer gets the page object from PageScript (also known as the scene), fetches the internal fonts and images from [Static Assets](https://developers.cloudflare.com/workers/static-assets/), rasterizes everything into an image buffer, and then returns the buffer to the engine in a format that the client can display like a JPEG/PNG or PDF. A big part of the magic here is handled by another Blitz module, [blitz-paint](https://github.com/DioxusLabs/blitz/tree/main/packages/blitz-paint), which in turn uses Parley for shaping the characters into glyphs, choosing fonts, and breaking text into lines. **Workers’ built-in RPC system: same application, multiple isolates**  Cloudflare Workers have a [built-in remote procedure call (RPC) system](https://blog.cloudflare.com/javascript-native-rpc/) that allows you to call methods on other Workers, pass objects between them, and call methods on those objects. You don’t have to worry about API schemas, types, or authentication, you just call remoteFunction(...params) and it works. You benefit from the isolation and the resources of the remote Worker without losing the convenience of accessing all of their functions locally using JavaScript. Kitesurf uses this RPC system: the Engine Worker calls renderFrame() from the PageRenderer Worker over RPC using one single call and gets a PNG as the result. Because the renderer holds no page state (only a disposable cache), the engine can safely kill and relaunch it on any failed or stuck RPC call — making each render request self-contained, retryable, and its isolate cheap and throwaway. Kitesurf works. It already passes around 215,000+ [WPT tests](https://github.com/web-platform-tests/wpt), and we are adding hundreds of passing tests every week. Here you can see the evolution over time, up to the latest version since we started the project: It’s worth noting that the parts of a browser that are important to agents (e.g., CSS, DOM, HTML, selection, SVG, and XHR) have good coverage already. Even things that might not be particularly important in the context of agents, like streams, are now decently supported. Performance-wise, Kitesurf is doing pretty well. Below are the medians of five Browser Run [quick-action](https://developers.cloudflare.com/browser-run/quick-actions/) runs across a [14-URL corpus](https://kitesurf.cloudflare.app/corpus.txt) comparing Chromium with Kitesurf. Chromium wins the stopwatch because a [JIT](https://en.wikipedia.org/wiki/Just-in-time_compilation) that has already seen this page always beats a cold software renderer — and today it does, by about 1.7x. Most of that gap comes from rasterization and JPEG/PNG encoding, which we will keep optimizing. But Kitesurf wins on memory and CPU, the things that actually drive your bill, by 3-7x compared to what Chromium uses. Less memory means we can run more sessions, scale better, and fundamentally lower both our costs and yours. We highlighted the importance of testing in our design decisions, but we all know that no matter how many tests you have, a project isn't truly complete until Doom runs on it. Here’s Kitesurf running [https://silentspacemarine.com/](https://silentspacemarine.com/) from our little Doom [experiment](https://blog.cloudflare.com/doom-multiplayer-workers/) a few years ago. You can try Kitesurf with Browser Run today, **available for free while in beta**, behind per-account [limits](https://developers.cloudflare.com/browser-run/limits/). The [Browser Run CDP endpoint](https://developers.cloudflare.com/browser-run/cdp/) now supports Kitesurf as an option, so your existing client [Puppeteer](https://developers.cloudflare.com/browser-run/puppeteer/), [Playwright](https://playwright.dev/), [chrome-remote-interface](https://www.npmjs.com/package/chrome-remote-interface), or any AI Agent that speaks MCP and CDP, already works. All you need to do is add the `browser=kitesurf` parameter to our endpoints. For example, to use Kitesurf with Opencode see [Using with MCP clients (CDP)](https://developers.cloudflare.com/browser-run/cdp/mcp-clients/) in our developer documentation and use this configuration: Another way to use Kitesurf is with [Browser Run’s Quick Actions](https://developers.cloudflare.com/browser-run/quick-actions/). Again, just add `browser=kitesurf` to the quick action endpoint and it will work. For example, if you need a quick screenshot from Wikipedia, this will work just fine: **Use the Kitesurf Playground with Chrome DevTools** Another option to start exploring Kitesurf is to use our [public playground here](https://kitesurf.cloudflare.app/). You can type in any URL to see how Kitesurf renders the page and interact with it. One interesting feature of the playground is that we inject Chrome DevTools in the UI, so you can inspect expanded DOM elements, read console messages, and watch network activity while Kitesurf renders pages. More interestingly, we implemented the necessary CDP instructions for the [Memory panel](https://developer.chrome.com/docs/devtools/memory) to report the WebAssembly footprint of each isolate, including frames, so you can gain a clear understanding of the resources each page is consuming. Check our [Developer Documentation](https://developers.cloudflare.com/browser-run/) for all the details on how to use Kitesurf with Browser Run. As of today, Kitesurf correctly renders pages like [TodoMVC](https://todomvc.com/) (vanilla, React, Vue, Angular, Preact), Wikipedia, Hacker News, the Cloudflare Blog, and much of the Cloudflare dashboard. We will keep improving Kitesurf and increasing the percentage of WPT tests that pass, to improve compatibility for more complex web pages. Kitesurf is great for AI agents that need to render pages but can accept the trade-offs of not using a full-featured, pixel-perfect Chromium browser. It is also excellent for automations and applications that rely on one-shot [Quick Actions](https://developers.cloudflare.com/browser-run/quick-actions/), such as extracting content from a page or generating PDFs or screenshots, for compatible sites. Think of Kitesurf as an ephemeral, fully-isolated, stateless engine designed to exist only for the duration of a task, that scales well for bursty, AI-driven workloads. If you need to play video, render WebGL, negotiate a bot-challenge handshake with real TLS fingerprints, or start a ten-minute authenticated session that requires persistent state — Kitesurf isn’t yet the right option. Just use Browser Run’s default, which is powered by Chromium. The best way to know if a specific site is compatible with Kitesurf is to try it. You can do this by using the APIs or, more quickly, try it in our [public playground](https://kitesurf.cloudflare.app/). Explore the DevTools panels and see what’s happening behind the scenes, with particular attention to the console and the memory metrics. Kitesurf is twelve weeks old. The first commit was in May. Here are some of the things we're actively working on: Thank you for making it all the way here — we know this was a long and technical blog post, but hopefully an interesting one. We went into detail because we don't take lightly how important, but also how complex, it is to build a new browser, even a very specific one. Kitesurf is in its early stages, but we wanted to open it up to you as soon as possible and learn from your feedback. The team will be actively improving it with frequent updates focused on performance, efficiency, and compatibility. One last thing: we're going to open source Kitesurf once we're ready — hopefully soon. Our goal is to let any customer deploy their own version of Kitesurf on their own accounts, if they want to. So give it a try in the [playground](https://kitesurf.cloudflare.app/), keep an eye on our [changelog](https://developers.cloudflare.com/browser-run/changelog/), and come chat with the team on [Discord](https://discord.com/invite/cloudflaredev). Share your experience and send us feedback; we’ll be listening.