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 #
| Question | Answer |
|---|---|
| What shipped? | Public GitHub repocloudflare/kitesurf ,Apache 2.0 , with engine, renderer, DOM shims, and CLI packages |
| Why now? | Cloudflare said it always intended to open the engine so builders could audit, patch, and self-host on their accounts |
| Local URL | http://127.0.0.1:8787 afterpnpm run dev ; health check at/health |
| CDP endpoint | ws://127.0.0.1:8787/devtools/browser for Puppeteer-core |
| Production gate | Workers Paid for Dynamic Workers;Cloudflare Access mandatory before exposing a deploy URL |
| Managed alternative | Browser Run APIs if you do not want to operate Workers |
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:
| Component | Role |
|---|---|
| Blitz | HTML parsing, DOM, layout, painting |
| Stylo | CSS parsing, cascade, computed styles |
| Boa | JavaScript in Wasm when Dynamic Workers cannot run it natively |
| Linebender / Krilla | Text layout, 2D graphics, PDF output |
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 #
| Option | Best when | Watch out for |
|---|---|---|
| Managed Browser Run | You want APIs without operating Workers | Less control over patches and release cadence |
| Self-hosted Kitesurf | You need custom rendering fixes or air-gapped deploy patterns | You own Access, Dynamic Workers cost, and compatibility |
| Headless Chromium | You need maximum site fidelity today | Memory, cold start, and container ops |
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:
| Package | Failure symptom | Typical fix path |
|---|---|---|
| engine | CDP disconnects, 5xx from Worker | Check wrangler logs, Access headers |
| page-script | JS exceptions, missing APIs | File minimal HTML repro in GitHub |
| page-renderer | Blank screenshots, font gaps | Compare against WPT progress notes |
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:
- Enable Cloudflare Access on the Worker hostname before sharing URLs in Slack.
- Rotate service tokens used by Puppeteer the same way you rotate API keys.
- Log outbound fetches your agents trigger; a compromised prompt can turn Kitesurf into aopen relay .
- Segment accounts so a dev deploy cannot touch production DNS or billing.
- 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 #
| Question | Practical answer |
|---|---|
| Does open source change benchmarks? | No — it changes who can reproduce them on your pages. |
| Can I run without Bazel? | Not per current README; pnpm run dev wraps Bazel targets. |
| Will my login flows work? | Unknown until you test; plan fallback to Chromium for OAuth quirks. |
| Does CDP parity equal Chrome? | No — README warns some DevTools features are incomplete. |
| Can agents run headless in CI? | Yes locally; protect CI secrets because CDP is a powerful primitive. |
What this means for agent builders #
- Fork budget — Apache 2.0 lets you patch layout or CDP handlers without renegotiating a vendor contract.
- Colocation — Running beside Workers AI orVercel-class edge compute is closer when the browser itself is a Worker.
- Security default — PlanAccess on day one ; do not treat open source as safer than managed APIs.
- Eval loop — Re-run your internalsite 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.