Cloudflare Kitesurf Open Source: Deploy an Agent Browser on Workers

Cloudflare open-sourced Kitesurf on November 13, 2026, fulfilling a promise it made when the agent-first browser engine debuted during Agents Week in August. You can now clone the Rust and WebAssembly stack, run it on 127.0.0.1:8787, and pnpm run deploy it to your own Workers account under Apache 2.0.

The release matters because many agent harnesses still default to headless Chromium, which is heavy on memory and hard to colocate with cheap inference. Kitesurf keeps HTML parsing, CSS, JavaScript, and screenshots inside Workers, speaks Chrome DevTools Protocol (CDP), and pairs naturally with Puppeteer or any CDP client your coding agent already drives.

TL;DR: what changed on November 13

What Kitesurf is (and is not)

Kitesurf is not a Chromium fork. According to the November 13 announcement and the repository README, it parses HTML, applies CSS, executes page JavaScript, and renders screenshots without Chrome or a browser container. It exposes CDP so tools built for Puppeteer can attach.

That design trades site compatibility for density. Our August coverage noted Kitesurf often used roughly three to seven times less memory and CPU than headless Chromium in Cloudflare benchmarks, with higher wall-clock latency on some real pages. Open source does not change those trade-offs; it lets you measure them on your workloads and contribute fixes.

Kitesurf open source agent browser architecture diagram on Cloudflare Workers Image: Cloudflare

Stack inside the repository

The blog post and README credit several Rust projects compiled to WebAssembly:

Engine, page-script, page-renderer, dom-shim, core, and kitesurf-cli live under packages/, which is the layout Cloudflare expects contributors to extend.

Kitesurf open source repository packages layout for agent browser engine Image: Cloudflare

How to run Kitesurf locally today

Cloudflare documents a Bazel-first workflow on the README. Requirements include Bazelisk, Node.js 22+, pinned pnpm 9.15.4, and on macOS GNU tar.

From a clean clone:

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

The first compile builds Rust core and vendored crates, so expect a long initial build. Later runs reuse Bazel cache. The engine listens on port 8787 unless you set KITESURF_PORT.

Puppeteer smoke test

The announcement shows puppeteer-core connecting to the local WebSocket:

import puppeteer from "puppeteer-core";

const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser",
});

try {
  const page = await browser.newPage();
  await page.goto("https://example.com/");
  await page.screenshot({ path: "page.png" });
} finally {
  await browser.disconnect();
}

For agent builders, the important line is the CDP endpoint. Harnesses like Chrome DevTools MCP or custom LangGraph tools can swap the browser URL without rewriting task logic, as long as your pages fit Kitesurf compatibility limits.

Chrome DevTools in a tab

With pnpm run dev, open http://127.0.0.1:8787/ in Chrome to load the landing UI, paste a URL, and inspect through DevTools. The README also documents chrome://inspect discovery on 127.0.0.1:8787. Bundled DevTools (--config=devtools) removes Google's hosted frontend limits but downloads about 250 MB on first build.

Deploying to your Cloudflare account

From the repository root:

pnpm run deploy

Wrangler uploads the Worker built by Bazel. The README is blunt: do not leave the Worker public. Without Cloudflare Access (Zero Trust) or equivalent, anyone who discovers the predictable kitesurf.<subdomain>.workers.dev pattern can:

• Browse the web through your account egress
• Burn Dynamic Workers and CPU you pay for
• Attach Puppeteer or other CDP clients

Cloudflare recommends enabling Access before deploy, or immediately after step one. For CDP automation behind Access, create a service token and pass CF-Access-Client-Id and CF-Access-Client-Secret headers in puppeteer.connect, per the README.

That security model intersects with Cloudflare's modern security write-up for agent pentest orchestrators: browser automation is outbound attack surface. Treat a Kitesurf Worker like an open proxy unless Access policies wrap it.

What developers are saying

The Hacker News thread was still thin at publish time, with early comments pointing readers to the GitHub repo. Broader agent-browser discourse this week focused on compatibility testing versus cost per session. If you try Kitesurf on production targets, record pass or fail per domain the same way you would for any non-Chromium engine, and share minimal reproductions in GitHub issues as Cloudflare's contribution guide requests.

Kitesurf vs managed Browser Run vs Chromium

If your agent only needs structured fetches without full layout, a plain HTTP client plus readability passes may still beat any browser. Kitesurf wins when JavaScript execution or faithful screenshots are required and Workers locality matters.

Compatibility and contribution expectations

Cloudflare states Kitesurf is experimental and under heavy development. The blog focuses on Web Platform Test progress and reliability. CONTRIBUTING.md requires maintainer vouching before large pull requests, and favors minimal reproductions over sweeping rewrites.

For teams comparing agent infra, read Cloudflare's September update chain on WebMCP in the August launch companion and watch whether your harness expects full Chrome APIs that Kitesurf does not implement yet.

Bazel, Dynamic Workers, and the page lifecycle

The README is explicit that Bazel builds everything: toolchains, wasm-bindgen, and binaryen downloads are pinned so contributors get reproducible artifacts. That choice trades setup time for hermetic builds — reasonable for a browser engine that must ship the same Wasm bits to local wrangler and remote Workers.

Each browsing session spins Dynamic Workers for isolated page and renderer instances. That pattern mirrors how Cloudflare described PageScript isolates at launch: JavaScript and layout stay compartmentalized instead of sharing one long-lived Chromium process. The cost is plan gating: teams on free tiers should assume they can develop locally but cannot honestly load-test production traffic without budgeting Workers Paid pricing docs linked from the repository.

Understanding the three-package split helps when you debug agent failures:

Security checklist before you point agents at the internet

The README warning block is unusually strong for Cloudflare. Treat it as a pre-deploy gate, not boilerplate:

1. Enable Cloudflare Access on the Worker hostname before sharing URLs in Slack.
2. Rotate service tokens used by Puppeteer the same way you rotate API keys.
3. Log outbound fetches your agents trigger; a compromised prompt can turn Kitesurf into a open relay.
4. Segment accounts so a dev deploy cannot touch production DNS or billing.
5. Re-read SECURITY.md before exposing internal staging sites that lack auth.

Agent teams already running Chrome DevTools MCP should decide whether Kitesurf replaces Chromium for a subset of tasks (structured scraping, screenshot regression) while keeping Chromium for fallback fidelity.

When to stay on Browser Run or Chromium

Browser Run remains the lowest-friction path if you only need managed scale and accept Cloudflare's compatibility roadmap. Self-hosting wins when you must:

• Patch layout or CDP behavior and ship the patch before the next managed release.
• Run browsers inside the same account as custom Workers AI routes for latency experiments.
• Audit Wasm sources for compliance reviews that block opaque containers.

Against Browserbase skills for Claude Code, Kitesurf is lighter but less mature. Our Browserbase comparison post is the right anchor when your harness already expects hosted Chromium.

A green cursor following a curved path across blank browser tab outlines, illustrating multi-tab agent browsing

What people ask before adopting Kitesurf

What this means for agent builders

1. Fork budget — Apache 2.0 lets you patch layout or CDP handlers without renegotiating a vendor contract.
2. Colocation — Running beside Workers AI or Vercel-class edge compute is closer when the browser itself is a Worker.
3. Security default — Plan Access on day one; do not treat open source as safer than managed APIs.
4. Eval loop — Re-run your internal site smoke suite before migrating production agents off Chromium.

Related reading

• Cloudflare Kitesurf launch architecture — August 2026 benchmarks and V8 isolate design
• Chrome DevTools MCP setup guide — CDP clients agents already use
• AWS Bedrock AgentCore runtime — another pattern for hosting agent tools at scale
• Ramp Inspect cloud coding agent — how one team operationalized always-on agent sandboxes
• Sparseread token-efficient agent reading — when you might skip a browser entirely
• Cloudflare security model for agent orchestrators — threat model for outbound agent traffic

Repository structure, pricing, and compatibility statements reflect Cloudflare's November 13, 2026 announcement and README as we fetched them.