---
title: "Cloudflare OS Explained: Architecture, Gatekeepers, Gadgets"
description: "A senior lab's technical guide to Cloudflare OS: the agent workspace, Gadgets on Dynamic Workers, the Gatekeeper security model, taint tracking, the full..."
source: "https://www.kensink.com/technologies/cloudflare-os/"
canonical: "https://www.kensink.com/technologies/cloudflare-os/"
---
★ Cloudflare OS guide Technologies & Infrastructure Apache-2.0

CLOUDFLARE OS · OPEN SOURCED 5 AUG 2026

# Cloudflare OS. An agent that can reach your systems without holding the keys.

Cloudflare ran it internally from May 2026, then open-sourced it in August. It gives every person a browser workspace with an agent grounded in company context, lets anyone build small full-stack apps without a developer, and puts a capability layer between those agents and the systems they act on. The interesting part is not the workspace. It is that an agent here starts with access to nothing and never once holds a credential. This is a full technical read: the architecture, the security model, the stack, what it is good for, and what it costs.

Cloudflare Workers Durable Objects MCP TypeScript Open weights

[Start your own workspace →](https://www.kensink.com/contact) [Cloudflare’s announcement ↗](https://blog.cloudflare.com/cloudflare-os/)

Open sourced

5 Aug 2026

Licence

Apache-2.0

Running inside Cloudflare since

May 2026

Infrastructure floor

Workers Paid plan

\[THE SHORT VERSION\]

## Three things in one platform.

Most coverage stops at 'AI workspace', which undersells it. Cloudflare OS is really three products that only make sense together: a grounded agent, a way for anyone to build software, and a permission system strict enough that the first two are safe to give people.

01

### The agent workspace

A browser tab per person, grounded in curated company context and a shared skills library. It researches against internal data, writes documents, slides, and spreadsheets that can stay connected to live sources, and runs workflows on a schedule or an external trigger. The skills library is the part that compounds: a procedure one person gets right becomes something everyone can run.

02

### Gadgets, the apps anyone can build

Full-stack applications written by the agent or the user. Each one gets its own sandbox: a Dynamic Worker for server code, a Durable Object Facet with a private SQLite database for state, a sandboxed browser frame for the UI, and Cap'n Web carrying calls between them. Private by default, shareable two different ways, editable forever. No developer required to make one, and no blast radius when one breaks.

03

### The security and governance layer

The reason this is interesting rather than another chat wrapper. Agents start with access to nothing. Reaching a company system means asking for one named resource, getting human approval, and receiving a typed function rather than a key. Gatekeepers hold the credentials, scope the access, mask fields, rate limit, and log every resource observed, which is what makes safe sharing possible later.

\[ARCHITECTURE\]

## What happens between a person and a company system.

Four tiers. The thing worth noticing is how little trust each one extends to the next: the workspace cannot reach the network, the sandbox cannot reach the network, and the only path out is a Worker that holds the credential and decides what comes back.

Person Company system

01

Surface

A browser tab. No install, no new infrastructure for the user.

Agent workspace

Chat, research, docs, slides, sheets

Skills library

Org-wide procedures, reusable

Cloudflare Access

Identity checked per request

02

Kernel

One Durable Object per workspace. This is what makes it multiplayer.

workshop-backend

Session, state, orchestration

Durable Object

Per workspace, real-time

AI Gateway

Every inference call routed here

03

Execution

Agent-written code runs here, with outbound networking off by default.

Gadget

One app, one sandbox

Dynamic Worker

V8 isolate, ms cold start

DO Facet + SQLite

Private database per app

04

Mediation

The only way out. No agent ever holds a credential.

Gatekeeper

Holds OAuth, scopes, masks, logs

MCP Server Portal

Existing MCP servers plug in

Typed binding

env.PROJECT.listIssues()

Read it top to bottom as one request. The workspace never talks to GitHub. It asks the kernel, which runs code in a sandbox that cannot reach the network, which calls a gatekeeper that holds the credential and decides what comes back.

\[TECHNOLOGY STACK\]

## Every primitive it runs on, and why.

Cloudflare OS is a showcase for a decade of Workers platform work. Several of these primitives shipped in 2026 specifically because this needed them, which is why the whole thing is hard to reproduce on another cloud.

| Component | Role | What it does here |
| --- | --- | --- |
| 
Cloudflare Workers

 | 

Runtime

 | The runtime everything sits on, including the open-source workerd if you self-host outside Cloudflare. |
| 

Dynamic Workers

 | 

Sandbox

 | Runs agent-generated code in a V8 isolate rather than a container. Cloudflare puts this at roughly 100x faster startup on about a tenth of the memory, which is what makes a per-app sandbox affordable. Outbound networking is off by default. |
| 

Durable Objects

 | 

State

 | One per workspace. This is why a workspace is real-time and multiplayer rather than a single-player chat window. |
| 

Durable Object Facets

 | 

Per-app database

 | Lets dynamically loaded code instantiate its own Durable Object with a private SQLite database. A supervisor object handles logistics and access control; the facet holds the app's data and cannot read the supervisor's. Open beta, Workers Paid plan. |
| 

Cap'n Web

 | 

RPC

 | Cloudflare's open-source object-capability RPC system, JavaScript-native, used between a Gadget's browser client and its server. Capability-based by design, which is the same idea the security model uses one layer up. |
| 

Cloudflare Access

 | 

Identity

 | Identity. Zero trust by default: every user and every request is verified before anything is served. |
| 

Cloudflare AI Gateway

 | 

Model routing

 | Every inference call routes through it. That is where model choice, provider swapping, cost attribution per person or team or workspace, and budget enforcement live. Local models through Ollama are supported, which removes the third-party-provider question entirely. |
| 

MCP Server Portals

 | 

Tool integration

 | Existing Model Context Protocol servers plug in as a source of tools, so an organisation that already invested in MCP does not start over. |
| 

Gatekeepers

 | 

Mediated access

 | Service-specific Workers, one per external system. Cloudflare ships them for GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Slack, Spotify, ZoomInfo, Home Assistant, and Email Workers. Each needs its own OAuth setup. |

Sourced from Cloudflare’s announcement post, the press release, the cloudflare/cloudflare-os README, and the Dynamic Workers and Durable Object Facets docs, all read on 14 August 2026. This is early-access software and the surface is moving, so check the repo before you budget against any specific number here.

\[SECURITY MODEL\]

## Default deny, and no agent ever holds a key.

This is the part worth copying even if you never deploy Cloudflare OS. The industry default is to hand an agent an API key and hope the prompt holds. Here, approval produces a typed function instead, and the credential stays in a Worker the agent cannot see.

1.  01
    
    ### The agent starts with nothing
    
    No tokens, no scopes, no ambient network. An agent that has just been created cannot reach a single company system, and neither can the code it writes.
    
    default deny
    
2.  02
    
    ### It asks for one resource
    
    Not "GitHub". One repository, read-only. The request is scoped at the resource level and a human approves it. High-impact writes can require approval every time, not once.
    
    human in the loop
    
3.  03
    
    ### It gets a typed binding, not a key
    
    Approval produces a function it can call. The OAuth credential stays inside the gatekeeper, invisible to the agent and to any code the agent generates.
    
    capability, not credential
    
4.  04
    
    ### Every read is written down
    
    The gatekeeper logs which resources were touched, masks fields it should not return, and applies rate limits. That log is attached to whatever the agent produced.
    
    observation log
    
5.  05
    
    ### Sharing re-checks the reader
    
    When the output is shared, gatekeepers re-check the recipient's own access to every source the agent read. You cannot launder data to a colleague through a document.
    
    taint tracking
    

What the agent sees

```
const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});
```

A typed method on a binding. There is no token in this code, no base URL, and no way to widen the scope from inside the sandbox.

What the gatekeeper holds

-   OAuth credential. Never leaves the gatekeeper Worker
-   Resource scope. One repo, one project, read-only
-   Field masking. Strips what should not come back
-   Rate limits. Per agent, per resource
-   Approval rules. Which writes need a human
-   Access log. Every resource observed

\[SHARING\]

## Two ways to share, and the difference matters.

Getting this wrong is how internal tools leak. One mode shares the running thing, data and all. The other shares only the shape of it. Cloudflare separated them deliberately.

Same instance

Direct share

-   Live shared state
-   Real-time multiplayer
-   One source of truth

Recipient needs their own access to everything the agent read.

A copy of the code only

Blueprint share

-   Independent state
-   Own connected resources
-   Recipient edits freely

No original data, history, or credentials travel with it.

\[USE CASES\]

## Where it earns its place.

Cloudflare reports thousands of internal users across every function, many of them not engineers. That is the tell: the value shows up in the roles where a general assistant is least useful, because the answer depends on internal policy and internal data.

Support and success

An agent that reads the ticket system through a scoped gatekeeper, drafts the reply in your voice against your actual policy documents, and escalates on rules a human wrote. The skill is shared, so every rep runs the same procedure.

Finance and ops

Spreadsheets that stay connected to the source instead of going stale the moment they are exported. A recurring close checklist that runs on a schedule, pulls the numbers, and flags only the lines that moved.

Sales

Account research assembled from internal CRM plus enrichment, with field masking so the agent never sees the columns it has no business seeing. A Gadget that tracks a pipeline the way one team actually runs it, not the way the CRM insists.

Engineering

Read-only access to one repository, issue triage that respects your labels, and internal dashboards built in an afternoon by whoever needed them. Container support for development workflows is on the roadmap, not shipped.

People and legal

The functions where a general assistant is least usable, because the answer depends on internal policy. Grounding plus per-resource access is precisely the combination those teams have been missing.

Anyone with a repetitive job

The strongest argument in Cloudflare's post: if you can build a tool to do a job yourself, an agent can use that tool to do the job when you are not there. Gadget plus schedule plus gatekeeper is that sentence made concrete.

\[ DEPLOYING IT \]

## What it takes to stand one up.

Three paths, in ascending order of how much you own. The demo takes minutes. A deployment your company actually uses takes gatekeepers, and gatekeepers take OAuth setup and access policy, which is the real work.

01

### Run it locally

```
git clone cloudflare/cloudflare-os
pnpm install
pnpm run-local
```

Serves on localhost:8787. Enough to judge whether the workspace model fits how your teams work. No Cloudflare account touched.

02

### Deploy the starter

```
os.cloudflare.app/deploy
or cloudflare-os-starter
```

Into your own Cloudflare account, in minutes. This is where the Workers Paid plan requirement bites, because Dynamic Workers will not run on the free tier.

03

### Make it yours

```
Gatekeepers per system
Skills library
Access + AI Gateway policy
```

The part that is a project rather than a command. One gatekeeper per external service, each with its own OAuth setup, scoping, masking, and approval rules.

A managed offering through the Cloudflare dashboard is announced but not shipped, and Cloudflare names Presidio and Happy Cog as launch partners for enterprise rollout. Container support for development workflows and a Slack integration are on the roadmap.

\[OUR TAKE\]

## What we would tell a client about it.

We build on Cloudflare daily, so read this as enthusiasm with the caveats attached rather than a launch summary. The architecture is the most serious answer we have seen to the agent-access problem. The product around it is young.

01

### Cloudflare calls v2 early access with many rough edges. Believe them.

That is a direct quote from the README, not our editorialising. External pull requests are discouraged beyond trivial fixes under twelve lines, which tells you the project is moving fast internally and is not yet shaped for outside contribution. Plan a pilot, not a rollout.

02

### The free tier cannot run this.

Gadgets need Dynamic Workers, which need a Workers Paid plan, and Durable Object Facets are in open beta on the same plan. It is easy to read an Apache-2.0 announcement as free and discover the infrastructure line afterwards. Size Workers Paid plus Durable Objects storage plus inference before you commit.

03

### An isolate is not a VM, and taint tracking is still evolving.

The sandbox is a V8 isolate, which buys speed and density and carries a different escape threat model than a container or a virtual machine. Cloudflare also describes the observation and approval machinery as still evolving. Both are reasonable for internal tooling. Neither is a finished answer for regulated data, and we would not pretend otherwise to a client.

04

### Gadget sprawl is a governance problem you will get eventually.

The thing that makes this good, anyone can build and fork an app, is the thing that produces two hundred half-maintained internal tools in eighteen months. Nobody has solved this. Decide early who owns retirement, and treat the skills library as the curated layer rather than letting every Gadget be a fork.

05

### You still have to trust your model provider, unless you do not use one.

The gatekeeper model contains what an agent can reach. It does not by itself stop a provider seeing what the agent read. Routing local models through Ollama removes that concern and costs you capability. That trade should be a deliberate decision, made per workload, not a default someone inherited.

\[METHODOLOGY · K-FRAMEWORK\]

## Integrated through the  
K-Framework.

Every model we integrate runs through the same operating system. Three pillars, sixteen layers, one Compound Growth Loop. The methodology that keeps AI work from rotting after the first ship.

[Read the K-Framework](https://www.kensink.com/k-framework)

01

### Foundations

Direct API integration with the model. No LangChain, no orchestration vendor, no agent framework built on quicksand. Typed contracts, the same way we wire up Postgres.

02

### Amplification

An eval suite built from your real tasks gates every prompt and model change. Quality is measured before it ships, not vibed in a demo.

03

### Judgment

Governance, audit, and oversight wired in from day one. Who called what, with which prompt version, at what cost. Your auditors get answers, not screenshots.

\[OBSERVABILITY\]

## Observability your team can read.

A model in production without observability is roulette. We instrument every integration so engineering and finance can see the same numbers, and so a regression at 3am surfaces before a customer opens a ticket.

Instrumented

### Cost per call

Tokens in, tokens out, dollars spent. Sliced by feature, tenant, and route. Budgets enforced where it matters.

Instrumented

### Latency p50 / p95 / p99

Real distributions, not averages. We know which routes are slow, and why.

Instrumented

### Eval pass rates

The same eval suite that gates a release runs continuously in production. A regression on real traffic surfaces fast.

Instrumented

### Prompt + completion logs

PII scrubbed at the proxy, shipped to your SIEM. Retention controls match your compliance window.

Dashboards your team owns, not ours. At handoff you get the queries, the alerts, and the runbook. We are not in the path to read your metrics.

\[COMMON QUESTIONS\]

## Questions we are getting asked.

What is Cloudflare OS, in one sentence?

It is an open-source workspace that gives each person in a company an AI agent grounded in that company's context, plus the ability to build small applications, with a security layer that lets the agent reach internal systems without ever holding a credential. Cloudflare open-sourced it on 5 August 2026 under Apache-2.0 after running it internally since May 2026.

Is it an operating system?

Not in the kernel-and-drivers sense, and Cloudflare is fairly upfront about the analogy. The claim is that it schedules and isolates AI workloads and mediates their access to resources, which is the job a traditional OS does for processes. Treat the name as positioning. The useful question is whether the isolation and mediation are real, and on that the architecture is more serious than the name suggests.

What does it actually cost to run?

The software is free and Apache-2.0. The infrastructure is not: Gadgets run on Dynamic Workers, which require a Cloudflare Workers Paid plan, so the free tier cannot run this. On top of that you pay for inference, which flows through AI Gateway where an administrator sets budgets and can attribute spend per person, team, or workspace. The honest budget line is Workers Paid, plus Durable Objects storage, plus whatever your model calls cost.

How is this different from giving everyone ChatGPT or Claude?

A general assistant knows the world and nothing about your company. Cloudflare OS is built around the opposite bet: the agent is grounded in your terminology, your procedures, and your systems, and it can act on them through mediated access. The trade is that somebody has to build and maintain that grounding, the gatekeepers, and the skills library. This is a platform, not a subscription.

Is the security model actually sound?

The design is stronger than most: default deny, capability bindings instead of shared keys, per-resource scoping with human approval, and taint tracking that re-checks a recipient's access when work is shared. Two honest caveats. Cloudflare describes the taint-tracking and approval systems as still evolving, and the sandbox is a V8 isolate rather than a container, which is a different threat model from a VM. It removes the worst practice in the field, which is handing an agent a long-lived API key.

Can non-developers really build apps with it?

That is the design goal, and Cloudflare reports thousands of internal users across non-engineering functions. The realistic reading is that non-developers can produce genuinely useful small tools: a tracker, a dashboard, a form that writes to a real system. What they cannot do is own the gatekeepers, the access policy, or the deployment, which is exactly the work that decides whether the whole thing is safe.

Should we deploy it now or wait?

It depends on why you want it. If the goal is to learn what agent-plus-internal-systems does to your workflows, deploy the starter into a non-production account this quarter, wire two gatekeepers, and find out. If the goal is a company-wide rollout on regulated data, wait for the managed dashboard offering and treat the current release as a design study. Cloudflare's own README calls v2 early access with many rough edges, and we take that at face value.

Share[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.kensink.com%2Ftechnologies%2Fcloudflare-os%2F&text=Cloudflare%20OS%2C%20taken%20apart)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.kensink.com%2Ftechnologies%2Fcloudflare-os%2F)

[View .md](https://www.kensink.com/technologies/cloudflare-os.md)

\[RELATED\]

## Worth a look next.

[

TECHNOLOGY

Cloudflare Workers, in production

Read more

](https://www.kensink.com/technologies/cloudflare-workers/)[

TECHNOLOGY

The agent harness, explained

Read more

](https://www.kensink.com/technologies/harness/)[

PATTERN

Multi-agent systems

Read more

](https://www.kensink.com/patterns/multi-agent/)

DEPLOYED, GROUNDED, GATEKEPT

## Start your own  
workspace.

We deploy Cloudflare OS into your account, write the gatekeepers for the systems your team actually uses, seed the skills library from how you already work, and hand you the access policy and the runbook. Full source ownership, no retainer by default.

[Start your own workspace →](https://www.kensink.com/contact) [All technologies](https://www.kensink.com/technologies)
