Michael JohnsonDoes every AI agent need to launch full Chromium just to read a page or take a screenshot? On November 12, 2026, Cloudflare open-sourced Kitesurf, an experimental browser engine for these automated tasks. It can run locally or be deployed in your Cloudflare account; the key trade-off is lower CPU and memory use in exchange for slower execution and limited website compatibility.
This offers browser automation developers a useful option: they can explore and adapt the engine while keeping the familiar Chrome DevTools Protocol (CDP) interface. But migrate all your workflows to Kitesurf only after testing the pages you need. In Cloudflare’s published comparison, Chromium completed the test tasks faster, and Kitesurf still lacks some important web features.
What changed on November 12
Kitesurf was first introduced on October 6, 2026, as a component of Browser Run, available in beta. At the time, Cloudflare described the architecture and results of its own tests; on November 12, the company released the code under the Apache 2.0 license. The engine can now be studied, built locally, and deployed on infrastructure in your account. This broadens access to the implementation, but does not by itself make the experimental browser a replacement for Chromium.
There are two ways to run the project. Local development requires Node.js 22 or later, pnpm 9.15.4, and Bazelisk; the project guide recommends cloning the repository, installing dependencies, and starting the build with pnpm run dev. Deployment on Cloudflare requires a Workers Paid plan: the engine uses Dynamic Workers to isolate pages. When self-hosting, you need to set up authentication separately—Kitesurf has none built in, and a public Worker URL could let outsiders use your account’s compute resources and make outbound requests.
How the browser works without Chromium
A conventional headless browser launches a large engine designed for websites and user interfaces. Kitesurf assembles the functionality needed for automation from several Workers components: one accepts CDP connections and stores session state, separate isolated processes handle the page, and another handles rendering. Kitesurf supports CDP for interaction with developer tools, so compatible clients such as Puppeteer can connect to it.
HTML and CSS are handled by Rust components, page JavaScript runs in an isolated Workers environment, and a separate renderer produces the image. Cloudflare describes routing network requests through a dedicated component that loads site resources, applies network policies, and stores page cookies separately. Isolation is part of the browser’s design: agents must open arbitrary websites containing code that cannot automatically be trusted.
The architecture suits a workload pattern of “start a task — process a page — finish.” If the renderer hangs, it can be stopped and restarted because it does not store page state. This approach could be more convenient for automation bursts than keeping heavy processes running continuously. That is an architectural motivation for the project, not a guarantee of specific savings on every user’s system.
How it reduces resource use
In an earlier published comparison, Cloudflare used the median of five Browser Run executions across a set of 14 URLs. For taking a screenshot, Kitesurf used 57.8 MiB of memory versus 271 MiB for a warm Chromium pool; for extracting HTML, it used 39.4 MiB versus 273.7 MiB. These figures describe a specific configuration and set of company-selected pages, so they are best read as measurements of one workload, not a universal multiplier for every website.
Chromium was faster on the same tasks: taking a screenshot took 637 ms, compared with 1,148 ms for Kitesurf, while HTML extraction took 472 ms versus 820 ms. In other words, Kitesurf’s advantage is primarily lower resource use, not faster responses. For large-scale, short-lived page collection, memory costs may matter more than a delay of a few seconds; for an interactive agent that needs to respond quickly, the time difference could outweigh the savings. Cloudflare published the methodology and results.
When to choose Kitesurf and when to choose Chromium
Kitesurf suits one-off tasks: retrieving HTML, building a DOM, taking a snapshot, or generating a PDF on a compatible site. Its CDP compatibility makes it possible to test this alternative in an existing automation stack, while the open-source code lets teams inspect its behavior and deployment requirements. For a small experiment, start with a local build; for a Cloudflare deployment, account for the paid plan and protect the instance with authentication.
For a site that uses video or WebGL, a long-running authenticated session, reliable handling of bot protection, or precise page rendering, Cloudflare’s documentation recommends the standard Chromium-based Browser Run browser. Kitesurf does not yet support video playback, WebGL, or long-running sessions that preserve state; standards support and rendering quality are still being developed.
There is also an important difference between standards compliance and real-world compatibility. Web Platform Tests check individual web-standard requirements, but do not tell you whether a particular complex website will load or whether an agent can correctly carry out a sequence of actions on it. The practical approach is to run the specific pages and workflows you need, comparing the results with Chromium, rather than inferring compatibility from the overall number of tests passed.
Practical takeaways for teams
Consider Kitesurf a specialized option for running browser tasks. First, choose a few real pages and measure three things: the accuracy of extracted data or screenshots, execution time, and resource use. Then separately check authentication, network restrictions, and session behavior. If the task is short, the site is compatible, and memory and CPU matter more than latency, Kitesurf is worth piloting. If precise rendering, rich web features, or persistent state are essential, Chromium remains the more suitable starting point.
Open-sourcing the code does not change the choice between a lightweight, specialized engine and a full-featured browser; it makes it possible to inspect and deploy the former independently. Teams can now more easily evaluate it on their own pages and infrastructure instead of relying solely on a vendor’s comparison tables.
