Cloudflare announced on November 13, 2026 that Kitesurf, its experimental browser engine for AI agents, is now available as open source under the Apache 2.0 license. Developers can inspect and modify the code, run it locally, or deploy their own instance on Cloudflare Workers.
The public repository gives developers the option to operate and alter the engine in their own Cloudflare accounts instead of relying solely on its managed Browser Run APIs. Cloudflare had promised this step when it introduced Kitesurf on August 6, 2026, and again in a September 28, 2026 update that added WebMCP support, expanded browser API and Browser Run coverage, and introduced terminal rendering.
Inside Kitesurf’s Agent-Focused Design
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 control interface used by Chrome DevTools and compatible automation software, allowing Puppeteer clients and AI agent harnesses to connect.
Internally, the Engine coordinates browser sessions and client connections, PageScript runs the page and its JavaScript, and PageRenderer produces the visual result. Cloudflare’s Developer Platform is combined with 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. Boa provides a fallback JavaScript runtime inside WebAssembly when the page’s code cannot run in Dynamic Workers.
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 access the network directly.
Statelessness is another part of that design. The Engine retains session state, while other components are disposable where possible, allowing capacity to track bursts of agent activity. PageRenderer holds no persistent page state, so the Engine can replace it after a failed or stalled rendering request.
Self-Hosting Requirements and Security
Local development requires 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 initial build compiles the Rust core and vendored dependencies, while later builds reuse Bazel’s cache. Developers can then 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 testing locally, operators can deploy the engine to their own account as an alternative to Browser Run’s managed APIs.
Self-hosting also transfers an important security responsibility. 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 a public interval.
Experimental Status and Contribution Process
Kitesurf remains experimental and under heavy development. The repository describes it as a CDP endpoint rather than a complete Chrome implementation, with some Chrome DevTools features still unsupported. Cloudflare 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 limitations illustrate the compatibility checks that still matter for agent workloads, even where a lighter browser’s resource use is attractive.
The contribution process is structured around that ongoing work. Cloudflare asks prospective contributors to open an issue with a minimal reproduction or proposed approach and obtain maintainer vouching before submitting a pull request. Focused changes with tests and a defined scope are preferred, although reproducible rendering bugs, failing automation workflows and documentation corrections are also welcome.
For developers, the trade-off 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.
Credit: Source link
