Cloudflare Open-Sources Kitesurf, Its Stateless Browser Built for AI Agents

Why a browser engine belongs on the edge

When AI agents started browsing the web in production, most teams reached for the same toolbox: Chromium in a container, Puppeteer on top, and a farm of warm instances waiting for the next task. That model works, but it is heavy. Every navigation spins up memory-hungry processes, every idle tab still costs money, and scaling across regions means shipping opaque browser images to data centers that were never designed to behave like desktop machines. Cloudflare’s answer is Kitesurf—a browser engine built for agents that runs on Workers instead of inside Chrome—and in November 2026 the company released it under the Apache 2.0 license, inviting the community to inspect, fork, and deploy their own copies.

The timing is not accidental. Agents are no longer demos that click through a handful of pages. They reconcile invoices, monitor competitor pricing, fill multi-step forms, and recover from JavaScript-heavy SPAs that assume a full browser. At the same time, inference budgets are tight: teams want the model to think, not to wait on a cold browser pod. Kitesurf reframes the problem as infrastructure on the edge—stateless sessions, per-page isolation via Dynamic Workers, and rendering pipelines compiled to WebAssembly—rather than as yet another fleet of headless Chromium.

From promise to open source

Cloudflare introduced Kitesurf in August 2026 as a “stateless browser for AI agents” that lives entirely on Workers. September brought WebMCP support, expanded APIs, and compatibility fixes aimed at real sites rather than toy HTML. Each announcement repeated the same commitment: the engine would eventually be open source so developers could run their own instance on their own Cloudflare accounts instead of relying solely on managed Browser Run APIs. That promise materialized on November 12–13, 2026, with the repository landing on GitHub, a developer changelog, and a blog post from Celso Martinho, Rui Figueira, Bernardo Pereira, and Luís Duarte walking through architecture and deployment.

Apache 2.0 matters for more than licensing optics. Agent platforms are consolidating around composable stacks—model APIs, tool runtimes, retrieval, and now browsing. Permissive open source lowers the cost of auditing what an agent actually executes when it “opens” a page, and it gives security teams a path to patch behavior without waiting for a vendor release cycle. Cloudflare still offers a managed path, but the default posture is no longer “trust our black box browser cluster.”

What Kitesurf actually does

Kitesurf is a browser engine in the narrow, precise sense. It parses HTML, applies CSS, executes page JavaScript, and can emit screenshots or PDF output. It is not a desktop browser with tabs and extensions. It does not bundle Chromium. Instead, it stitches together Rust components—many compiled to Wasm—that implement the rendering pipeline on Workers.

The stack is worth naming because it explains both strengths and limits:

• Blitz handles HTML parsing, the DOM, layout, and painting (MIT OR Apache-2.0).
• Stylo implements CSS parsing, cascading, and computed styles (MPL-2.0).
• Boa runs JavaScript in WebAssembly when Dynamic Workers cannot execute page script directly.
• Linebender libraries (Parley, Vello, Kurbo, Peniko) cover text layout and 2D graphics.
• Krilla supports PDF generation.

Three internal packages divide responsibility: the Engine manages browser sessions and client connections; PageScript runs the page and its JavaScript; PageRenderer draws the result. That separation mirrors how production agent systems think—session orchestration, execution sandbox, and artifact extraction are different concerns with different scaling profiles.

Critically, Kitesurf speaks the Chrome DevTools Protocol (CDP). Existing automation clients such as Puppeteer can attach without rewriting agent tool code around a bespoke RPC layer. Full CDP parity is explicitly not a goal yet; Cloudflare documents gaps. For teams migrating from Chromium, the practical question is whether their workflows depend on obscure DevTools domains or on the common subset (navigation, DOM queries, screenshots, network hooks). The answer determines how painful adoption will be.

Workers, Dynamic Workers, and the economics of isolation

Running a browser on Workers is only possible because Cloudflare can spawn Dynamic Workers—isolated Workers instances—for individual pages. That model trades the familiar process-per-tab Chromium layout for something closer to serverless functions with hard sandbox boundaries. Kitesurf requires a Workers Paid plan for Cloudflare deployment because Dynamic Workers are not available on the free tier. Local development uses Wrangler (pnpm run dev after cloning the repo and installing dependencies with pnpm).

The economic story is about burst scale and geographic distribution rather than keeping N browsers warm in us-east-1. An agent that needs to check a dashboard in Tokyo and a regulatory filing in Frankfurt benefits when rendering happens near the origin and tears down when the task completes. Whether that beats containerized Chromium on cost depends on page complexity, JavaScript time, and screenshot frequency—but the architectural bet is clear: agents should not inherit the memory footprint of software built for humans staring at screens for hours.

Statelessness is another design pillar. Managed Browser Run APIs and self-hosted Kitesurf deployments are oriented toward ephemeral sessions: load, act, capture, discard. That fits tool-calling loops where the LLM needs a fresh DOM snapshot, not a persistent logged-in profile—though nothing stops you from layering cookie jars and storage on top if your threat model allows it.

Security: the deployment footgun everyone should read

Open-sourcing Kitesurf does not remove operational risk; it surfaces it. Cloudflare’s README is unusually blunt: do not deploy without authentication in front of the engine. Kitesurf has no built-in auth. Anyone who can reach your endpoint can browse the public web through your account’s egress, attach CDP clients, and consume CPU and Dynamic Worker quota on your dime. The default workers.dev hostname follows a predictable pattern (kitesurf.<subdomain>.workers.dev), which makes accidental public exposure worse.

The recommended mitigation is Cloudflare Access (Zero Trust) or another identity layer in front of the engine. Agent operators should treat a Kitesurf URL like an unauthenticated HTTP proxy with a JavaScript runtime attached—a powerful capability that must sit behind the same controls you would use for internal admin APIs.

For AI security reviews, this is the checklist item that separates toy deployments from production: secret scanning on pages, SSRF policies, allowlisted domains, and rate limits must be enforced above Kitesurf, not assumed from the engine.

Where agents win—and where Chromium still wins

Kitesurf optimizes for lightweight, high-volume agent browsing: fetch rendered state, run scripts needed for the task, return structured observations. It will struggle, relative to mature Chromium builds, on bleeding-edge web platform features, complex media pipelines, and sites that detect non-mainstream engines. Cloudflare labels the project experimental and under active development, with ongoing work on standards support, rendering fidelity, and performance.

Teams should plan a bimodal strategy:

1. Kitesurf path for scalable, CDP-compatible automation where pages are mostly document-and-form workflows and JavaScript is moderate.
2. Full browser path for flows that require extensions, codecs, or guaranteed Chrome compatibility testing.

The open-source release makes that split easier to implement in one codebase: the same Puppeteer calls, different backend URL, feature flag on fallback.

Building and deploying your own instance

The repository documents build requirements, Bazel involvement, and patch series under scripts/patches/. The happy path for contributors is:

git clone https://github.com/cloudflare/kitesurf.git
cd kitesurf
pnpm install --frozen-lockfile
pnpm run dev

The local dev server typically listens on http://127.0.0.1:8787, with CDP clients attaching to the documented endpoint. Production deploy uses pnpm run deploy from the repo root after you have validated changes locally—again, only behind authentication.

Because third-party components retain their own licenses, the NOTICE file is part of compliance due diligence for enterprises redistributing modified engines. That is standard in Apache projects, but agent vendors packaging Kitesurf into hosted products should treat NOTICE aggregation as a release gate.

WebMCP and the agent toolchain

September’s WebMCP support positioned Kitesurf inside the broader move to standardize how models discover and invoke tools. Browsers are not just retrieval channels; they are interactive surfaces where agents commit transactions. A Workers-native engine reduces the latency between “model decided to click” and “DOM updated,” which matters when tool loops are budgeted in seconds.

Pairing Kitesurf with Workers AI, KV, Durable Objects, or queues is the natural Cloudflare-shaped architecture: session state in Durable Objects, ephemeral renders via Kitesurf, post-processing in a Worker, model call on Workers AI or an external API. Open source lets you replicate that pattern on your account even if you do not use every managed product.

What open source changes in the market

Before Kitesurf, the agent-browser layer was dominated by Chromium derivatives and a handful of proprietary remote browser vendors. That concentration created vendor risk: pricing power, opaque security patches, and regional availability tied to whoever operated the fleet. An Apache-licensed engine backed by a major edge network is not a panacea, but it introduces credible fork pressure and inspectable behavior—two things enterprise procurement teams have started asking for as agent workloads move from pilot to production.

Competition will respond. Expect managed browser vendors to emphasize Chrome fidelity and enterprise SLAs, while edge platforms push cost and scale stories. Developers benefit when both axes advance.

Practical takeaways for engineering leads

If you are evaluating Kitesurf this quarter, run a structured bake-off rather than a demo on your marketing site:

• Measure end-to-end latency for your top ten agent workflows, including cold start on Workers.
• Compare screenshot and accessibility tree quality against your Chromium baseline.
• Enumerate CDP features you rely on and map them to Kitesurf’s supported surface.
• Model cost with Dynamic Worker usage and egress, not just CPU seconds on a VM.
• Put Cloudflare Access (or equivalent) in the architecture diagram on day one, not week six.

If you are building a platform for other people’s agents, open source is an opportunity to offer bring-your-own-browser-engine tenancy: customers deploy Kitesurf in their Cloudflare org, your control plane stores only session metadata and tool policies. That alignment with data residency and egress policies is increasingly a sales requirement.

Cloudflare’s Kitesurf release is best understood as infrastructure maturation for agentic systems. Models improved first; tool protocols followed; now the heavy, stateful components—browsing, document rendering, authenticated web sessions—are being refactored for the same serverless, edge-native world that reshaped HTTP APIs a decade ago. Whether you adopt Kitesurf directly or not, the design constraints it embodies—stateless sessions, Wasm render pipelines, CDP compatibility, explicit auth boundaries—are becoming the default template for agent-scale web interaction.

The repository is live, the license is permissive, and the engine is honest about being experimental. For teams shipping agents in 2026, that combination is an invitation to prototype on production-shaped infrastructure instead of bolting another Chromium fleet onto an already expensive stack.