Kitesurf is now open source: Kitesurf, our experimental browser engine

Cloudflare launched the open-source release of Kitesurf under the Apache 2.0 license on GitHub, fulfilling the release roadmap it outlined during the software's initial rollout. The company first introduced Kitesurf in August as an experimental stateless browser engine designed specifically for artificial intelligence agents running entirely on Cloudflare Workers, and later added WebMCP support, updated APIs, and broader compatibility in September. Developers can inspect the source code, execute the engine on local development machines, and deploy dedicated instances across Cloudflare's edge network, according to details shared in Cloudflare Blog's report.

This report details the architectural components, local setup workflows, deployment specifications, and engineering requirements behind running the open-source Kitesurf engine. It is written for software engineers, systems architects, and machine learning teams evaluating self-hosted browser automation runtimes for autonomous AI agents. The release provides an alternative to managed Browser Run endpoints by allowing teams to control browser infrastructure directly on their own cloud infrastructure.

01Containerless execution across global Workers network

Kitesurf operates directly on the Cloudflare Workers runtime without relying on standard container virtualization or headless Chromium instances. The engine ingests web resources, parses incoming HTML documents, applies cascading style rules, executes JavaScript within page contexts, and generates visual screenshots entirely inside lightweight Worker environments. Because the architecture removes traditional container overhead, it consumes significantly less memory and CPU resources while scaling on demand across Cloudflare's distributed edge infrastructure.

The runtime exposes standard Chrome DevTools Protocol support directly over network sockets, enabling programmatic access for existing automation clients. Automation libraries such as Puppeteer connect seamlessly to the engine's endpoints, allowing development teams to navigate pages and capture DOM state using standard browser automation interfaces. This compatibility allows AI agents and orchestration harnesses that target CDP interfaces to control the browser runtime without requiring custom protocol adapters.

02Compiled Rust packages and internal subsystems

The Kitesurf codebase relies on an ecosystem of open-source Rust crates compiled directly into WebAssembly modules. Document layout, HTML parsing, DOM tree representations, and visual painting are powered by the Blitz project, while the Stylo engine handles CSS parsing, style cascade calculations, and computed properties. Text layout algorithms and 2D rendering operations run on Linebender libraries, document export workflows utilize the Krilla crate for PDF generation, and Boa executes JavaScript inside WebAssembly whenever execution cannot proceed in Dynamic Workers.

The repository organizes these responsibilities across three primary runtime subsystems that separate orchestration, script execution, and visual rasterization. The Engine component manages active browser sessions and incoming client connections, the PageScript subsystem isolates page evaluation and JavaScript execution, and the PageRenderer subsystem draws visual outputs. All components reside within dedicated directories inside the packages folder, including the Rust core modules, DOM shims, rendering pipelines, and the standalone Kitesurf command-line interface.

03Local development workflow and Puppeteer automation

Engineers can run Kitesurf locally by cloning the public GitHub repository and initiating dependency installations using the frozen lockfile flag in pnpm. The initial local build compiles the core Rust code and third-party WebAssembly dependencies, populating a persistent build cache that accelerates subsequent rebuilds. Once compilation completes, the Wrangler development tool starts a local server bound to port 8787, exposing an interactive interface for Google Chrome DevTools alongside WebSocket endpoints for programmatic control.

Automated processes connect to the local development environment over a dedicated WebSocket URL path that routes commands into the engine. A standard Node.js script using the puppeteer-core package connects to the exposed browser endpoint, initializes a blank page session, navigates to target web domains, and writes captured screenshot files to local storage. AI execution harnesses interface directly with the same CDP port, granting agent frameworks real-time programmatic control over page interactions and visual inspection.

04Cloudflare Workers deployment and runtime requirements

Teams that finish local modifications can package and deploy their custom Kitesurf instances directly onto personal or enterprise Cloudflare accounts. Running the deploy script through pnpm packages the engine assets and publishes the application directly to Workers, offering an independent alternative to Cloudflare's managed Browser Run service. Self-hosting the engine enables engineering teams to modify rendering behavior, test custom shims, and eliminate external API rate dependencies.

Deploying Kitesurf to production infrastructure requires an active Cloudflare Workers Paid subscription plan. The engine requires the platform's Dynamic Workers feature to instantiate isolated, ephemeral Worker environments for every individual web page session. These dynamic instances isolate untrusted script execution and prevent state crossover between distinct browser navigation contexts, ensuring strict security boundaries during automated web crawling sessions.

05Web Platform Tests and community contribution

Cloudflare maintains the Kitesurf codebase as a public development project on GitHub and coordinates broader technical discussions on its official Discord server. Engineering efforts currently prioritize improving standards conformance, expanding runtime reliability, and validating compatibility against standardized Web Platform Tests suites. Maintainers regularly publish benchmark data and test suite progression figures on the project's documentation pages to track rendering fidelity over time.

Prospective contributors must consult the repository's contribution guidelines and open an issue with reproduction details before submitting pull requests. Project maintainers require contributors to receive formal issue endorsement prior to opening code reviews, emphasizing narrowly scoped pull requests accompanied by automated tests over sweeping architectural refactors. The project also accepts non-code contributions, including minimal reproduction files for rendering discrepancies, failing automation traces, and documentation improvements.