Cloudflare has released the source code for Kitesurf, a browser engine for AI agents, under the Apache 2.0 license. The engine loads web pages, runs JavaScript, and renders pages to images. It runs on Cloudflare Workers without launching a Chrome container. Tools such as Puppeteer can connect to it through the Chrome DevTools Protocol (CDP), which is used to control and inspect browsers remotely.
Cloudflare announced plans to open-source the engine when the beta launched on August 6, announced the release in a November 12 changelog entry, and explained the details in a blog post on the 13th. Alongside the existing Browser Run managed API, developers can now fetch the code, try it locally, and deploy it to their own Cloudflare accounts. Running it yourself, however, means meeting the runtime requirements and protecting external connections on your own.
Comparison of usage options
Kitesurf is less a browser that a person operates with tabs and windows than an engine that processes web pages on instructions from automation tools. Alongside the route through the Browser Run managed API that Cloudflare provides, anyone who fetches the published code can examine or change its internals. Modified code can be tested locally or deployed to your own Workers.
| Usage option | Where it runs / entry point | How to start | Conditions you need to prepare |
|---|---|---|---|
| Managed API | Managed API provided by Cloudflare | Use the Browser Run managed API | Follow the terms of the provided API |
| Local development | Your local environment, wrangler dev | Fetch the code, install dependencies, and start it | Bazelisk, Node.js 22 or later, pnpm 9.15.4, etc. |
| Self-deployment | Your own Cloudflare Workers account | Deploy with pnpm run deploy |
Workers Paid plan and authentication settings to protect connections |
Note: A comparison of usage routes and starting conditions as presented at the November 2026 release. Based on the announcement, the README, and the changelog.
The managed API, local development, and deployment to your own Cloudflare account differ in where the engine runs and what the operator is responsible for. Self-deployment requires both a paid plan and external authentication. The Apache 2.0 release of the core code is a separate matter from the contract and authentication needed to run it on Workers.
Inside the browser, rebuilt with Rust and Wasm
The published implementation divides the work from connection to rendering into three roles. Engine manages sessions and client connections, PageScript runs the page and its JavaScript, and PageRenderer handles drawing. The repository's packages directory holds the Rust core, a substitute DOM implementation, and the renderer and CLI as separate pieces.
Following how a page is processed, Blitz parses the HTML, builds the DOM, and handles layout and rendering. The design uses Stylo for CSS parsing and for computing styles from combined rules. Linebender libraries support text layout and 2D rendering, and Krilla handles PDF output. The Rust components are compiled to WebAssembly (Wasm) and combined with Workers APIs.
JavaScript execution also has a division of labor. Page JavaScript is handled on the PageScript side, with the Boa JavaScript engine as a last resort when Dynamic Workers cannot run it. In its August design explanation, Cloudflare said it uses Boa because Workers cannot execute native eval. In other words, there is a fallback path for handling code that pages evaluate dynamically.
Developers can read and modify the code of each component, but the distribution as a whole is not under a single license. Kitesurf itself is published under Apache 2.0, while dependency libraries, fonts, and data retain their own licenses. For example, Stylo is MPL-2.0 and Blitz is MIT or Apache-2.0, with notices recorded in the accompanying NOTICE file. Anyone redistributing or modifying the code should also check the terms of each component they use.
With self-deployment, you also decide who may connect
To try it locally, the build environment described in the README is the starting point. Install Bazelisk as bazel, and prepare Node.js 22 or later and pnpm 9.15.4. On macOS, GNU tar is also required. After fetching the repository, install dependencies with pnpm install --frozen-lockfile, then run pnpm run dev, which builds the Rust and Wasm components and then starts wrangler dev.
The first build takes time, and later builds use the cache. Locally, it listens on 127.0.0.1:8787, and the README includes an example that connects from Puppeteer, opens a page, and saves a screenshot. These are descriptions based on the published procedures; we did not actually run or deploy it for this article.
To deploy to your own Cloudflare account, use pnpm run deploy. Because Kitesurf creates a separate Worker for each page, it needs Dynamic Workers, which require the Workers Paid plan. Even though the code is public, the execution resources on this officially documented deployment route come with usage conditions.
Deciding who is allowed to connect to a deployed engine is then the operator's job. In the changelog, Cloudflare cautioned that "Kitesurf has no built-in authentication." workers.dev URLs are public by default, and the naming patterns can be guessed. Anyone who connects to the URL can use DevTools and CDP, send outbound traffic from the deployer's account, and consume paid CPU and Dynamic Workers resources.
The README advises protecting the deployed URL with Cloudflare Access or similar. Preview Version URLs are also exposed, so they need to be included in the protection. There is a window between deploying and configuring Access during which the URL is exposed, but the README also describes a way to enable Access in advance for all Workers in the account.
Once Access is enabled, the automation side needs authentication too. A CDP client without a session obtained by logging in through an ordinary browser will be blocked as is. In the Puppeteer method the README shows, you issue an Access service token, allow it with a Service Auth policy, and pass CF-Access-Client-Id and CF-Access-Client-Secret as headers when opening the WebSocket connection. The token carries the same privileges as a signed-in user, so it must be managed as a secret.
Adoption depends on your target sites and automation tasks
CDP gives existing automation tools a way to connect. In the README's Puppeteer example, the client connects to the local CDP endpoint, creates a page with newPage, opens it with goto, takes a screenshot, and disconnects. Kitesurf does offer a CDP endpoint, but it is not a full implementation of Chrome and does not support some Chrome DevTools features. Cloudflare describes the engine as experimental and under active development.
So beyond whether you can connect, it is worth checking whether a full workflow completes on the sites you want to operate on. Testing page rendering, JavaScript behavior, and action results with your existing scripts, and checking how faithfully screenshots reproduce pages, will inform an adoption decision. Cloudflare says its goal is to use less CPU and memory than a full browser, but for this release it has not presented new performance measurements or operating costs for individual workloads. Once you have confirmed that the work you need can be done, the next step is to measure the time and resources it takes.
Cloudflare lists improvements in compatibility, reliability, and efficiency as priorities, and welcomes reproducible pages, failing automation steps, and documentation fixes. To contribute, you open an issue, obtain a maintainer's vouch, and then open a pull request. Reporting failures you can reproduce on your target sites helps the developers while you judge whether the engine fits your use, and it can feed back into improving the published engine.