Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Research: Cloudflare, Cap’n Proto, Workers RPC, and Cap’n Web

Research note last checked 2026-04-30. This file summarizes Kenton Varda’s Cloudflare work and Cloudflare’s Cap’n Proto-derived RPC stack, with capOS design consequences.

Executive Summary

Cloudflare is the most important modern production context for Cap’n Proto. Kenton Varda, the creator of Cap’n Proto, is the lead engineer for Cloudflare Workers, and Cloudflare’s Workers team is now the primary maintainer of the main C++ Cap’n Proto/KJ implementation. Cloudflare uses Cap’n Proto/KJ in the Workers runtime, Durable Objects, sandbox/supervisor and cross-machine communication, internal service bindings, and Workers RPC. Cap’n Web is a separate JavaScript-native sibling protocol inspired by Cap’n Proto rather than a Cap’n Proto/KJ-based runtime system.

The main capOS lessons are:

  • Typed Cap’n Proto RPC is a practical production bridge for systems written in Go/Rust/C++ and JavaScript, not merely historical prior art.
  • Object-capability RPC can be a normal developer-facing API, not just a kernel/protocol mechanism. Workers RPC and Cap’n Web both expose object references, functions, promise pipelining, and capability-style security.
  • Production systems distinguish the core runtime from the full security product. workerd is open source and capability-shaped, but Cloudflare warns that it is not by itself a complete secure sandbox.
  • Cap’n Proto RPC remains resource-exhaustion-sensitive. capOS must add its own quota/resource-ledger discipline at every remote-capability boundary.
  • Cap’n Web shows a separate web-facing branch of the same design family: schema-free, JSON-based, TypeScript-friendly, HTTP/WebSocket/postMessage transports, but still object-capability RPC with promise pipelining.

Source Map

Primary sources read:

  • Kenton Varda’s Cloudflare author archive, used as the inventory of his posts.
  • Cap’n Proto FAQ and Cap’n Proto 0.9 release notes.
  • Cloudflare blog posts:
    • “Durable Objects in Dynamic Workers: Give each AI-generated app its own database”
    • “Sandboxing AI agents, 100x faster”
    • “Code Mode: the better way to use MCP”
    • “Introducing workerd: the Open Source Workers runtime”
    • “We’ve added JavaScript-native RPC to Cloudflare Workers”
    • “Why Workers environment variables contain live objects”
    • “Building Cloudflare on Cloudflare”
    • “Cap’n Web: a new RPC system for browsers and web servers”
    • “Eliminating Cold Starts 2: shard and conquer”
    • “Zero-latency SQLite storage in every Durable Object”
    • “Durable Objects: Easy, Fast, Correct – Choose three”
    • “Dynamic Process Isolation: Research by Cloudflare and TU Graz”
    • “Mitigating Spectre and Other Security Threats: The Cloudflare Workers Security Model”
    • “Introducing lua-capnproto: better serialization in Lua”
  • Cloudflare developer docs:
    • Workers RPC
    • Workers RPC visibility/security model
    • Durable Objects overview
    • Dynamic Workers bindings

Cloudflare and Kenton Varda

The Cap’n Proto FAQ says Cloudflare Workers is led by Kenton Varda and that Workers heavily uses Cap’n Proto. It also says the Cloudflare Workers team is now the primary developer and maintainer of Cap’n Proto’s main C++ implementation.

The Cap’n Proto 0.9 release notes state that Cap’n Proto development had become primarily driven by Cloudflare Workers. At that point Workers had already moved from mostly using KJ to heavily using Cap’n Proto RPC for Durable Objects.

For capOS, Cloudflare is strong evidence that:

  • Cap’n Proto RPC is still a living system, not only Sandstorm-era history.
  • KJ’s async/runtime design matters because it is deployed in Workers.
  • Cap’n Proto’s object-capability RPC model is compatible with large-scale production infrastructure, but only with additional platform hardening and resource controls.

The full author archive also includes posts that are not Cap’n Proto-specific but are relevant to capOS architecture:

  • live object bindings as capability-shaped environment entries
  • Workers security and Spectre mitigation
  • Dynamic Process Isolation research with TU Graz
  • Durable Objects as single-threaded colocated compute/storage actors
  • Dynamic Workers for fast disposable isolate sandboxes
  • Code Mode for having agents write code against typed APIs rather than emit direct tool calls

workerd

workerd is Cloudflare’s open-source JavaScript/Wasm runtime, sharing most of the code that powers Cloudflare Workers. It is designed as a server runtime for Workers-compatible applications, local testing, and programmable proxy use cases.

Cloudflare explicitly warns that workerd alone is not a secure sandbox for untrusted code. The Workers service adds environment-specific hardening, including V8 patch automation, risk-profile separation, kernel features, and resource-limit enforcement. The project is also not an independent governance surface: Cloudflare Workers priorities drive the repository, and internal interfaces may churn.

capOS implications:

  • Borrow the shape, not the whole product. A capOS userspace JavaScript/Wasm runtime can learn from workerd, but must not assume workerd alone provides OS-grade isolation.
  • Treat runtime internals as unstable unless pinned. If capOS embeds or adapts workerd, the trusted-build-input and upgrade policy must account for churn.
  • Keep the capOS kernel/resource model as the isolation and quota authority; runtime-level object capabilities are an additional layer.

Live Object Bindings

Cloudflare Workers environment variables are not only strings. Bindings are live objects scoped to a specific Worker’s env parameter. A Worker cannot reach a protected service by guessing a URL or global name; it must hold the binding object. The post explicitly compares this to capability-based security: the binding designates a resource and confers permission to access it, is not in a global namespace, and must be invoked explicitly.

The post also notes that current Workers bindings are not a complete capability system because ordinary bindings are not generally passed dynamically between Workers yet, though future dynamic bindings are discussed.

capOS implications:

  • This strongly supports capOS’s bootstrap CapSet and broker-issued bundle model: authority should arrive as live objects/caps, not ambient service names plus bearer tokens.
  • It also supports treating the environment/capset as an explicit function parameter rather than global state. This preserves composition and testability.
  • It reinforces the policy that remote protocol fields, URLs, and names should not become authority by themselves.

Durable Objects

Durable Objects are Cloudflare’s single-threaded stateful actor-like compute units colocated with durable storage. Public posts describe them as an approach where code runs where the data is stored, often in the same thread as embedded SQLite, avoiding network storage latency. Earlier Durable Objects posts focus on race avoidance and correctness: single-threaded object execution makes it natural to keep state in memory while serializing operations that touch the same object.

Dynamic Worker Facets extend this idea to Dynamic Workers: generated code can run in a disposable isolate while using a per-app Durable Object facet with its own isolated SQLite-backed storage.

capOS implications:

  • Durable Objects are strong prior art for capOS service objects that combine single-threaded state, colocated storage, and actor-style request handling.
  • For paper-scoped persistence, a minimal service-owned store/object proof is closer to this model than to a global filesystem.
  • For hosted agents, per-task or per-app isolated storage facets are a useful pattern, but the storage capability must remain broker-issued and revocable.

Workers Security, Spectre, and Dynamic Process Isolation

Kenton’s Workers security posts separate API-level capability design from execution isolation. Workers uses V8 isolates for density, but wraps them with cordons, process isolation for higher-risk cases, Linux sandboxing, supervisor processes, local proxy mediation, V8 patch discipline, and timing/Spectre mitigations. Dynamic Process Isolation research with TU Graz addresses the harder Spectre isolation problem when many tenants share isolate infrastructure.

The “Sandboxing AI agents, 100x faster” post reuses this isolate foundation for Dynamic Workers: fast disposable isolates for AI-generated code, rather than heavyweight containers. The post emphasizes speed and density, but the security claim depends on the broader Workers platform, not a bare runtime library.

capOS implications:

  • Capability-shaped APIs are not a substitute for execution isolation. capOS should continue treating page tables/processes, resource ledgers, and future sandboxing as separate security layers.
  • If capOS runs AI-generated code, isolate-style fast startup is attractive, but the capOS trust boundary must include side-channel and resource controls.
  • For browser/Wasm proposals, Workers is evidence that isolates can scale, but also that Spectre/timing mitigations are first-order design constraints.

Cloudflare’s Cap’n Proto Uses

Cloudflare’s public sources describe several Cap’n Proto uses:

  • Workers runtime implementation: Cap’n Proto and KJ are core implementation pieces.
  • Sandbox/supervisor and cross-machine/datacenter communication.
  • Durable Objects: Cap’n Proto RPC is heavily used for communication in the system.
  • Internal Workers: Cloudflare added Cap’n Proto RPC bindings so internal Workers can call services such as Quicksilver, DNS, and DoS-protection systems. Schemas are bundled with the Worker at publication time, and the runtime converts JavaScript data to/from Cap’n Proto.
  • Worker sharding/cold-start reduction: cross-instance communication in the Workers runtime uses Cap’n Proto RPC, including capabilities to lazily loaded local Worker instances.
  • Older Cloudflare infrastructure: Cloudflare wrote lua-capnproto and used Cap’n Proto in logging/analytics pipelines before Kenton joined.

capOS implications:

  • A typed Cap’n Proto RPC bridge is a credible first remote-capability proof: Cloudflare uses schema-bundled service calls from JavaScript into internal Go/Rust services.
  • Lazy capabilities are useful for cold-start and placement problems. A remote cap may represent a lazily created service, but invocation must still be explicit and resource-accounted.
  • The capOS “capability proxy” should be framed as a service with explicit listen/connect authority, schema selection, and resource budgets, not a generic kernel network mode.

Workers JavaScript-Native RPC

Cloudflare Workers RPC lets Workers and Durable Objects communicate by calling methods on JavaScript classes exposed through bindings. It is built on Cap’n Proto but removes schema boilerplate from the JavaScript developer surface.

Key properties:

  • Calls are asynchronous regardless of whether the server method was declared async.
  • Parameters and return values can include structured-clonable data.
  • Functions and objects can be passed by reference; the receiver gets a stub and later calls back to the original location.
  • Calls to service bindings often stay in the same thread, reducing local RPC overhead dramatically.
  • When calls cross the network, promise pipelining lets dependent calls on a returned object travel in one round trip.
  • Security is object-capability based: a side can only invoke objects/functions for which it has received a stub.

capOS implications:

  • It is reasonable for capOS to expose developer-friendly language bindings above typed capability transport. The kernel ABI should stay narrow, but userspace runtime APIs can feel like method calls on local objects.
  • Promise pipelining is not optional polish for object-style APIs over latency. Cloudflare documents it as the mechanism that prevents API designs from collapsing into coarse ad hoc batch methods.
  • A local fast path matters. RPC calls that stay within one scheduler/runtime context should avoid unnecessary network-shaped overhead.

Code Mode and Agents

Kenton’s Code Mode post argues that agents should often write code against a typed API rather than emit raw tool calls directly. The Cloudflare claim is that MCP is useful as an API discovery/connection layer, but complex workflows are better expressed as code that calls a TypeScript API. This reduces token flow through the model when chaining operations and lets normal language tooling carry structure.

capOS implications:

  • This supports the capOS hosted-agent direction: present capability-scoped tools as typed APIs and let agents compose them in code under a sandbox, instead of exposing broad stringly tool surfaces directly to the model.
  • Approval gates should wrap the capability/API boundary, not be hidden inside prompt text.
  • Promise pipelining and object references may reduce tool-call latency, but only after authority and review gates are preserved.

Cap’n Web

Cap’n Web is a 2025 Cloudflare RPC protocol and TypeScript implementation by Kenton Varda and Steve Faulkner. It is explicitly described as a spiritual sibling to Cap’n Proto for the web stack.

Design differences from Cap’n Proto:

  • no Cap’n Proto schemas
  • JSON plus preprocessing for special values instead of Cap’n Proto binary encoding
  • TypeScript-friendly APIs
  • HTTP, WebSocket, and postMessage() transports
  • small dependency-free browser/server package

Shared design lineage:

  • object-capability RPC
  • bidirectional calls
  • functions and objects passed by reference
  • promise pipelining
  • capability-based security patterns
  • import/export tables for pass-by-reference objects

Cap’n Web also introduces a web-specific .map()-style pipelining feature that records a restricted non-Turing-complete instruction set derived from pipelined calls, addressing a GraphQL-like “waterfall” case.

capOS implications:

  • Cap’n Web is useful prior art for browser-hosted capOS experiments or web admin clients, not for the kernel ABI.
  • Schema-free RPC trades away capOS’s current “schema is permission surface” discipline. It may fit JavaScript/web adapters, but core capOS services should remain typed and schema-governed unless a proposal explicitly accepts the runtime-validation burden.
  • HTTP batch mode and broken references after batch completion are useful patterns for paper-scoped network-transparency proofs: short-lived remote caps can have explicit lifetime boundaries.

Security and Resource Warnings

Important warnings from primary sources:

  • Cap’n Proto’s serialization layer is intended to be safe against malicious bytes, but the reference implementation has not had a formal security review.
  • Cap’n Proto RPC is designed for mutually distrusting parties, but the FAQ warns that it is not robust against resource exhaustion attacks.
  • Cap’n Proto does not provide encryption by itself; use an encrypted transport such as TLS.
  • workerd is not a complete sandbox for malicious code without Cloudflare’s surrounding platform hardening.
  • Cap’n Web/Workers TypeScript surfaces do not automatically enforce runtime type checks merely because TypeScript types exist.

capOS implications:

  • Every remote-capability proposal must include resource ledgers for table entries, queued calls, queued bytes, streams, retries, and live objects.
  • The first capOS remote-capability proof should validate failure behavior: disconnect, overload, broken refs, stale refs, and malformed payloads.
  • Treat TypeScript or schema-free web adapters as convenience layers that require runtime validation at the trust boundary.
  • Encryption/authentication is a transport requirement, not something Cap’n Proto RPC gives for free.

Design Consequences for capOS

  1. The first external capability proxy should be typed and schema-bundled, closer to Cloudflare’s internal Worker-to-service Cap’n Proto RPC bindings than to full OCapN/CapTP compatibility.
  2. Developer ergonomics can improve above the transport: object stubs, language-native async calls, and promise pipelining are legitimate runtime APIs.
  3. Keep the kernel/user ABI and core service contracts schema-first. Cap’n Web is compelling for web-facing clients, but its schema-free design does not replace capOS’s typed authority model.
  4. Promise pipelining should be designed as a core performance and authority feature, not as an optional batching trick.
  5. Remote cap lifetimes need explicit scopes. HTTP batch-style broken refs, session-scoped refs, and disconnect-driven broken promises are all useful precedents.
  6. Resource exhaustion must be solved by capOS, not delegated to Cap’n Proto.
  7. Runtime isolation remains an OS responsibility. A language runtime can be capability-oriented while still needing kernel/VM/sandbox containment.

Sources

  • Cap’n Proto FAQ: https://capnproto.org/faq.html
  • Cap’n Proto 0.9 release notes: https://capnproto.org/news/2021-08-14-capnproto-0.9.html
  • Kenton Varda author archive: https://blog.cloudflare.com/author/kenton-varda/
  • Durable Objects in Dynamic Workers: https://blog.cloudflare.com/durable-object-facets-dynamic-workers/
  • Sandboxing AI agents, 100x faster: https://blog.cloudflare.com/dynamic-workers/
  • Code Mode: the better way to use MCP: https://blog.cloudflare.com/code-mode/
  • Introducing workerd: the Open Source Workers runtime: https://blog.cloudflare.com/workerd-open-source-workers-runtime/
  • We’ve added JavaScript-native RPC to Cloudflare Workers: https://blog.cloudflare.com/javascript-native-rpc/
  • Why Workers environment variables contain live objects: https://blog.cloudflare.com/workers-environment-live-object-bindings/
  • Building Cloudflare on Cloudflare: https://blog.cloudflare.com/building-cloudflare-on-cloudflare/
  • Cap’n Web: a new RPC system for browsers and web servers: https://blog.cloudflare.com/capnweb-javascript-rpc-library/
  • Eliminating Cold Starts 2: shard and conquer: https://blog.cloudflare.com/eliminating-cold-starts-2-shard-and-conquer/
  • Zero-latency SQLite storage in every Durable Object: https://blog.cloudflare.com/sqlite-in-durable-objects/
  • Durable Objects: Easy, Fast, Correct – Choose three: https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/
  • Dynamic Process Isolation: Research by Cloudflare and TU Graz: https://blog.cloudflare.com/spectre-research-with-tu-graz/
  • Mitigating Spectre and Other Security Threats: The Cloudflare Workers Security Model: https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/
  • Introducing lua-capnproto: better serialization in Lua: https://blog.cloudflare.com/introducing-lua-capnproto-better-serialization-in-lua/
  • Workers RPC docs: https://developers.cloudflare.com/workers/runtime-apis/rpc/
  • Workers RPC visibility and security model: https://developers.cloudflare.com/workers/runtime-apis/rpc/visibility/
  • Durable Objects overview: https://developers.cloudflare.com/durable-objects/concepts/what-are-durable-objects/
  • Dynamic Workers bindings: https://developers.cloudflare.com/dynamic-workers/usage/bindings/