Cloudflare Open-Sources Kitesurf, Its Chrome-Free Browser for AI Agents

Cloudflare open-sourced Kitesurf on November 13, 2026, giving developers the code to its experimental browser engine for AI agents under the Apache 2.0 license. Anyone can now inspect the code, modify it, run it locally, or deploy a private instance on Cloudflare Workers. The move fulfills a promise Cloudflare made when it launched Kitesurf on August 6, 2026, and repeated in a September 28, 2026 update that added WebMCP support, expanded browser API and Browser Run coverage, and introduced terminal rendering.

The release matters because agents increasingly need to browse the web, and running a full Chromium instance per agent is expensive. Kitesurf is Cloudflare's bet that agents don't need Chrome — they need a lighter engine that can still render, execute and report back.

What does Kitesurf actually replace?

Kitesurf turns HTML and CSS into rendered pages, executes page JavaScript, and produces screenshots without Chrome or a browser container. It exposes a Chrome DevTools Protocol (CDP) endpoint — the same control interface Chrome DevTools and compatible automation software use. That means Puppeteer clients and AI agent harnesses can connect to it without rewriting their tooling.

The internal architecture splits the work across several components:

• Engine coordinates browser sessions and client connections.
• PageScript runs the page and its JavaScript.
• PageRenderer produces the visual result.

Cloudflare built the stack on its Developer Platform plus Rust components compiled to WebAssembly. Blitz supplies HTML parsing, DOM, layout and painting; Stylo handles CSS; Linebender libraries cover text and 2D graphics; and Krilla creates PDF output. When a page's code can't run in Dynamic Workers, Boa provides a fallback JavaScript runtime inside WebAssembly.

In short: it's a browser engine assembled from Rust parts, speaking the protocol every automation tool already knows.

How does it stay cheap and safe?

Cloudflare says its design goal is to give agents the web access they need with lower CPU and memory use than a full Chromium browser, while scaling on demand across its Workers network. The original architecture treats every page load as untrusted input and isolates components according to the resources they require. A dedicated SandboxOutbound worker handles all external fetching, enforcing network policy and keeping each page's cookies separate; other components cannot touch the network directly.

Statelessness carries much of the scaling story. The Engine retains session state, while other components stay disposable where possible, so capacity can track bursts of agent activity. PageRenderer holds no persistent page state, which lets the Engine replace it after a failed or stalled rendering request. The takeaway: agents get elastic browsing capacity without operators paying for idle browser containers.

What does self-hosting require?

Local development needs Bazelisk, Node.js 22 or newer, and pnpm 9.15.4. The development command builds the WebAssembly modules and page and renderer bundles, then starts a local engine at 127.0.0.1:8787. The first build compiles the Rust core and vendored dependencies; later builds reuse Bazel's cache. From there, developers can inspect pages through Chrome DevTools or attach Puppeteer and other CDP clients.

Deployment on Cloudflare requires a Workers Paid plan, because Dynamic Workers create the isolated workers used for pages and renderers. After local testing, operators can deploy the engine to their own account as an alternative to Browser Run's managed APIs. The message to developers is straightforward: you can own the browser stack, but the plumbing is on you.

Who secures a self-hosted instance?

Self-hosting transfers an important security responsibility to the operator. The engine has no authentication of its own, and its workers.dev address is public by default. Without Cloudflare Access or another authentication layer, anyone with the URL could browse through the engine, connect CDP clients, issue requests originating from the operator's Cloudflare account, and consume paid CPU time and Dynamic Workers.

The repository instructs operators to protect the URL immediately and explains how to enable Access across the account before deployment to avoid any public interval. This is the sharpest edge of the release: the convenience of a public endpoint and the exposure of one are the same thing.

How complete is Chrome compatibility?

Kitesurf remains experimental and under heavy development. The repository describes it as a CDP endpoint rather than a complete Chrome implementation, and some Chrome DevTools features are still unsupported. Cloudflare says it is prioritizing compatibility, reliability and efficiency.

At the August launch, Cloudflare said Kitesurf was not yet suitable for video, WebGL, bot-challenge handshakes requiring real TLS fingerprints, or long authenticated sessions that depend on persistent state. Those gaps illustrate the compatibility checks that still matter for agent workloads, even where a lighter browser's resource use is attractive. If a target site leans on anti-bot TLS checks, Kitesurf will struggle today.

How can developers contribute?

The contribution process is structured around that ongoing work. Cloudflare asks prospective contributors to open an issue with a minimal reproduction or a proposed approach and obtain maintainer vouching before submitting a pull request. Focused changes with tests and a defined scope are preferred, though reproducible rendering bugs, failing automation workflows, and documentation corrections are also welcome.

The bar is deliberate: small, testable patches into a codebase that is still moving fast.

What's the trade-off for adopters?

For developers, the deal is direct control of the browser stack in exchange for securing the deployment themselves and accommodating an engine whose Chrome and web-platform compatibility remains incomplete. Managed Browser Run APIs still exist for teams that would rather not carry that load.

Whether Kitesurf becomes a default building block for agent infrastructure will depend on how quickly Cloudflare closes the compatibility gaps it has already named — video, WebGL, TLS-fingerprint challenges and persistent sessions — now that outside developers can see and fix the code themselves.