# Cloudflare Kitesurf Open Source: Deploy an Agent Browser on Workers

> Source: <https://explainx.ai/blog/cloudflare-kitesurf-open-source-workers-november-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog>
> Published: 2026-11-13 00:00:00+00:00

**Cloudflare open-sourced [Kitesurf](https://github.com/cloudflare/kitesurf?ref=explainx) on November 13, 2026**, fulfilling a promise it made when the agent-first browser engine debuted during [Agents Week in August](https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026). 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** repo`cloudflare/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` after`pnpm 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](https://developers.cloudflare.com/browser-rendering/?ref=explainx) 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](https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx) and the [repository README](https://github.com/cloudflare/kitesurf?ref=explainx), 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](https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx)*

### 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](https://blog.cloudflare.com/kitesurf-open-source/?ref=explainx)*

## 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:

``` python
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](https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026) 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](https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026): **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](https://news.ycombinator.com/item?id=50489156&ref=explainx) 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](https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026) 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:

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](https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026) 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](https://explainx.ai/blog/browserbase-skills-claude-code-browsing-2026) 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

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](https://explainx.ai/blog/vercel-labs-ui-sdk-behaviors-for-agents-react-vue-svelte-beta-2026) 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](https://explainx.ai/blog/cloudflare-kitesurf-agent-browser-v8-isolates-august-2026) — August 2026 benchmarks and V8 isolate design
- [Chrome DevTools MCP setup guide](https://explainx.ai/blog/chrome-devtools-mcp-chrome-devtools-for-agents-55k-stars-setup-skills-guide-2026) — CDP clients agents already use
- [AWS Bedrock AgentCore runtime](https://explainx.ai/blog/aws-bedrock-agentcore-runtime-next-generation-november-2026) — another pattern for hosting agent tools at scale
- [Ramp Inspect cloud coding agent](https://explainx.ai/blog/ramp-inspect-cloud-coding-agent-launch-74-percent-merged-code-2026) — how one team operationalized always-on agent sandboxes
- [Sparseread token-efficient agent reading](https://explainx.ai/blog/sparseread-token-efficient-agent-reading-layer-2026) — when you might skip a browser entirely
- [Cloudflare security model for agent orchestrators](https://explainx.ai/blog/cloudflare-modern-security-model-artex-pentest-orchestrators-2026) — 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.*