Kitesurf Goes Open Source As Cloudflare Browser For Agents

Posted on by
Contents show
Kitesurf

Browser engines like Chromium were built for people who like tabs, themes, and smooth scrolling, and almost none of that engineering helps an AI agent that only wants clean HTML, a screenshot, and a predictable failure mode. That mismatch is the entire reason Kitesurf exists. Cloudflare built Kitesurf as an agent first browser that runs entirely on top of Workers, without a browser container, without Chromium, and without the memory and compute bill that comes with giving every agent its own full browser instance. Twelve days ago it was a proprietary beta inside Browser Run. Now Cloudflare has open sourced the whole engine on GitHub under the Apache 2.0 license, which means anyone can read the source, run it locally with Wrangler, or deploy their own instance to their own Cloudflare account. This article covers what Kitesurf actually is, why a browser without a container matters, how the open source release changes the math for teams building agents, and where the project still falls short today.

What Kitesurf actually is

Kitesurf is a browser engine that parses HTML, applies CSS, executes page JavaScript, and renders screenshots, all inside the Workers runtime. There is no headless Chrome process anywhere in the stack, no browser container image to pull, and no Chromium license to think about. It speaks the Chrome DevTools Protocol, the same wire protocol that Puppeteer and Playwright drive, so existing browser automation clients can connect to a Kitesurf endpoint and mostly just work.

The engine started as an experiment twelve weeks before its August introduction, when Cloudflare engineers took inspiration from obscura, a headless Rust engine built for AI automation with no Chrome, no Node.js, and no dependencies. The first port to Workers barely worked. What changed the outcome was handing an AI agent a detailed plan and a clear definition of success, then letting it iterate in a loop with the Web Platform Tests as goalposts. The team curated which features the agents implemented and in what order, while human engineers focused on architecture and review.

The result is not a Chrome clone and does not pretend to be one. Kitesurf is deliberately light on what only humans need. Visual perfection and 60 frames per second scrolling are not goals; pixel exact CSS rendering can be slightly off and the agent will not care. What the engine optimizes for is the set of things an agent actually needs: structured machine readable content, predictable screenshots, low token counts in the output, and per task cost that does not require a frontier model budget. Cloudflare positions it in the Browser Run family, where it is available free in beta as an endpoint that agents can drive.

Why agents need a different browser

The argument for building a new engine instead of wrapping Chromium is economic before it is technical. A full browser instance carries tabs, extensions, device sync, accessibility trees, and rendering machinery that exist for human ergonomics. Agents use none of it. But every agent session pays for all of it, in memory, in cold start time, and in CPU. At agent scale, where a single workflow might open hundreds of page loads, that overhead makes per agent browser instances prohibitively expensive for anyone but the largest buyers.

There is also a threat model shift that Chromium was never designed around. When the entity driving the browser is a model, the dangerous inputs are not exploits against the rendering pipeline but prompt injection hidden in page content, and tool safety failures where an agent exfiltrates data through a page it was asked to visit. Kitesurf's architecture assumes every page load is untrusted input and every session starts fresh. Each component is isolated and holds access only to the resources it strictly needs, and the engine commits to one failure rule across the whole codebase: any fault degrades to a blank frame or a missing element, never a dead session.

That design posture mirrors what agents need from the wider stack, not just the browser layer. Teams evaluating the agent infrastructure market will recognize the pattern from the 2026 AI gateway comparison, where the winning platforms were the ones that treated model traffic as untrusted and added policy at the boundary. A browser is just another boundary, and Kitesurf treats it that way.

What the open source release includes

The November 12 changelog entry is short, but the scope is large. The entire engine source is now on GitHub under Apache 2.0. Developers can inspect how HTML parsing, CSS application, JavaScript execution, and screenshot rendering work inside Workers, fork it, and ship changes. Three deployment paths ship with the release.

Running locally is the first path. After following the build requirements and setup instructions, a developer starts the engine and a local Wrangler dev server with a single pnpm command. This is the fastest way to test whether an automation script that targets Chromium will run against Kitesurf, because the CDP surface means Puppeteer can connect to a local instance with almost no changes.

Self hosting on Cloudflare is the second path. The deployment instructions walk through pushing the engine into your own Cloudflare account, where it runs as your own Workers deployment. One operational detail deserves emphasis: Kitesurf provides no built-in authentication. Cloudflare explicitly instructs self hosters to protect their deployment with Cloudflare Access or another authentication layer before exposing it. An open browser endpoint on the public internet is a proxy for anyone who finds it, and the release notes are direct about that responsibility landing on the operator.

Contributing is the third path, and the process is deliberately gated. Cloudflare says review capacity is limited, so contributors must open an issue first, get vouched by a maintainer, and keep changes focused, following the contribution guidelines before submitting a pull request. That is a familiar pattern for infrastructure projects that expect drive by feature PRs to cost more in review time than they return, and it signals that the team expects compatibility, reliability, and performance to stay the priorities over breadth of features.

How Kitesurf runs without a container

The technical trick underneath Kitesurf is that the entire browser pipeline compiles to WebAssembly and runs inside V8 isolates on Workers. The team chose Rust compiled directly to WebAssembly through wasm-bindgen wherever possible, avoiding Emscripten and its many layers of mocked dependencies, which keeps the compiled engine close to the metal and the binary lean. Page JavaScript executes in the isolate runtime; HTML parses in Rust; CSS applies in Rust; and screenshots render from the engine's internal representation without ever instantiating a compositor designed for human eyes.

The maturity of the underlying platform is what made this conceivable in twelve weeks. Dynamic workers, SQLite backed Durable Objects, worker to worker RPC, service bindings, higher Node.js compatibility, and higher platform limits collectively turned Workers from a request handler into a place where complex stateful applications can live. A browser engine is about as complex as stateful applications get, and Kitesurf is the proof that the platform now carries that weight.

Testing strategy carried as much weight as the architecture. Conformance to web standards is measured against the Web Platform Tests, and Cloudflare publishes the project's WPT progress publicly so anyone can see which subsystems pass and which still fail. Standards conformance alone does not prove a browser is useful, so the team also built integration and visual regression suites that run multistep Puppeteer tests against real websites on both Chromium and Kitesurf, comparing both the assertions and the rendered output at every step to surface unwanted differences. Those two feedback loops, standards and real world, are how an engine written mostly by AI agents converges on behavior that real crawlers and computer use agents can rely on.

What this means for agent builders

For teams building computer use agents, the practical consequences fall into three buckets.

Cost per page load is the first. A Kitesurf session on Workers consumes isolate resources, not a full browser container, and Cloudflare claims significantly better CPU and memory efficiency than Chromium for the common agentic tasks of screenshots and HTML extraction. Teams that currently rent headless Chrome fleets or pay per browser hour can run the same workload through a Kitesurf endpoint and compare directly, because the CDP compatibility means the client code barely changes. The computer use agent space has been waiting for this cost curve to bend; projects like CUA Lite for computer use agents pushed on the model side, and Kitesurf pushes on the infrastructure side of the same equation.

Deployment control is the second. An open source engine under Apache 2.0 means an enterprise can run its own browser fleet inside its own account, behind its own Access policies, with no data passing through a third party endpoint beyond Cloudflare's network itself. Regulated industries that could not accept a shared browser service now have a self host path, and the cloud computer for AI agents pattern gets a concrete new building block at the browser layer.

Engine transparency is the third. When a page renders differently in Kitesurf than in Chrome, an agent team can now read the parser and find out why, file an issue, or patch it in their own deployment. That is a materially different situation from filing a Chromium bug and waiting, or from reverse engineering a closed browser API. Agent stacks have long had to treat the browser as an opaque dependency with mysterious failure modes, and the deep research crowd in particular will notice; retrieval agents that crawl dozens of sources per query, in the style of Exa's ultra deep research agent, are exactly the workloads where browser flakiness compounds into answer quality.

Hosted endpoint or self hosted deployment

The open source release creates a real fork in the road for agent teams, and the right choice follows from three questions.

The first question is who else can reach the browser. A team crawling public pages with no credentials involved can use the hosted Browser Run endpoint and never think about the security layer, because Cloudflare operates it. A team whose agents log into customer accounts, read internal dashboards, or handle personal data should self host behind Cloudflare Access from day one, because an unauthenticated browser endpoint with logged in sessions is a data breach waiting for a scanner.

The second question is volume and predictability. The hosted endpoint is free in beta, which is ideal for evaluation and low volume workloads, but beta pricing always changes and per request costs at agent scale deserve modeling before a production commitment. Self hosting on a Workers paid plan moves the cost onto the account's own usage curve, which is easier to forecast when the workload is steady.

The third question is patching. Teams that need a rendering fix or a protocol behavior change faster than the upstream review process can carry a private fork and deploy it themselves, something impossible with the hosted service. The honest recommendation is to prototype on the hosted endpoint, measure success rates on the real site mix, and move to self hosting when either the data sensitivity or the patching need becomes real.

The limits that remain

Cloudflare labels Kitesurf experimental and under heavy development, and the label is honest. Web standards support is incomplete, rendering fidelity is not pixel perfect, and performance work is ongoing, all tracked publicly through the WPT dashboard and the benchmark pages. Real world pages with heavy JavaScript, exotic CSS, or anti bot defenses will surface gaps that the integration tests have not caught yet.

The contribution gate is another limit worth planning around. Teams hoping to land a feature quickly should expect the issue plus vouching process to take longer than a typical open source project, because review capacity is explicitly limited. The pragmatic path for urgent needs is a fork: the Apache 2.0 license allows internal patches without upstreaming, and self hosting means those patches deploy immediately.

Authentication is the third operational gap. With no built-in auth, every self hosted deployment needs a security layer in front, and the kitesurf.dev playground is the only place a casual user can try the engine without building anything. Serious users should treat the deployment guide and the Access requirement as part of the install, not an optional extra.

The economics also deserve a caveat rather than a slogan. Cloudflare's efficiency claims compare Kitesurf against Chromium on common agentic tasks, which is the right comparison for the target workload but not a universal claim. A workload dominated by long JavaScript boot sequences or complex single page applications may see smaller gaps, and the public benchmark pages exist precisely so teams can check where the engine stands before designing around it.

Finally, Kitesurf does not aim at the full human web experience. Interactive web apps that depend on pixel exact layout, complex user gestures, or browser extension ecosystems will not behave identically to Chrome. For the target workload, agents reading pages, filling forms, and taking screenshots, the gaps matter less, but teams should validate their actual site mix against the engine before committing a production workflow.

Questions readers are asking

Is Kitesurf a replacement for Chromium based automation? Not yet, and maybe never for every site. Kitesurf targets agentic workloads such as HTML extraction, screenshots, and form interaction, where it runs with far less CPU and memory than a Chromium container. Sites that need pixel exact rendering or heavy browser extension behavior will still want a full browser. The practical migration path is to run both side by side through the same CDP clients and measure per task success rates.

What license is Kitesurf under and what can I do with it? Apache 2.0. You can inspect the source, fork it, modify it, run it locally, and deploy your own instance to your own Cloudflare account, including in commercial products, with the usual Apache 2.0 attribution requirements. Cloudflare asks contributors to follow the issue first and vouching process before submitting pull requests, but internal forks carry no such gate.

How do I connect my existing Puppeteer scripts to Kitesurf? Kitesurf implements the Chrome DevTools Protocol, so Puppeteer and other CDP clients connect to a Kitesurf endpoint the same way they connect to a headless Chrome instance. Most automation code needs only the endpoint URL changed. Behavior differences will show up on pages where Kitesurf's standards support is still incomplete, which is why the project publishes its Web Platform Tests progress for teams to check before migrating.

Does the open source release include the hosted Browser Run service? No. The open source repository contains the engine, which anyone can run locally or deploy to their own account. The hosted Browser Run product continues to run Kitesurf as a managed endpoint with its own pricing and limits, free in beta for now. Self hosting and the hosted service share the same engine code.

Who is behind the obscura inspiration story? The engine's origin traces to obscura, an open source headless browser engine written in Rust for AI automation with no Chrome, no Node.js, and no dependencies. Cloudflare engineers used it as the initial inspiration, attempted a port to Workers with the help of an AI agent, and then grew the working proof of concept into a full engine through the Web Platform Tests loop and real website integration testing. The shipped engine is Cloudflare's own code, published under Apache 2.0.

What happens if a page crashes the engine? The design rule is that any failure degrades to a blank frame or a missing element rather than killing the session. Every component is isolated with access only to the resources it needs, and every page load is treated as untrusted input with the session starting fresh. That containment posture is aimed directly at prompt injection and hostile pages that a computer use agent will inevitably encounter.

Sources
[fluentform id="2"]