Cloudflare OS: An Open-Source AI Agent Platform

What is Cloudflare OS, the open-source AI agent platform?

Cloudflare OS is the AI agent platform Cloudflare ran internally before open sourcing it in August 2026. It begins as a conversation in the browser, working from the context and skills an organization chooses. The repository carries the Apache-2.0 license.

Everyone at Cloudflare got access to the first version in May 2026. Thousands of people across every function, many outside engineering, use it daily for documents, slides, repeatable tasks and small data-visualization apps, Cloudflare says. The August release is a rewrite based on that experience.

The three parts of the AI agent workspace

Cloudflare splits Cloudflare OS into three parts: an agent workspace, a security and governance framework, and a platform for personal apps. In the workspace, a person talks to an agent in the browser, with no terminal or developer skills required.

To research a topic, a workspace writes code that searches, filters and joins data rather than pulling a whole dataset into the model. The result can become a document, presentation or spreadsheet that stays linked to live data. Where a file is not enough, the agent can build an app, and jobs with known steps can become mostly deterministic workflows that run on demand, on a schedule or on an event.

The README describes Cloudflare OS as an "operating system" for AI productivity, not a traditional computer operating system. The point, it says, is not for a company to adopt Cloudflare OS as it stands but to build its own "Your Company OS". The blog also links to a demo.

What Cloudflare learned from the first version

The first version was built around individuals in private workspaces, and Cloudflare names three problems with it, the last appearing once people began sharing work. Apps were static rather than live software connected to internal systems, and mostly deterministic jobs still re-ran an agent skill and burned more model tokens. Cloudflare's CIO, Sam Rhea, covers the internal journey in a separate blog post.

Visibility was the bigger problem. Access to an MCP server shows which tools an agent can call, but not which underlying resources it has looked at. With workspaces, apps and outputs being shared, Cloudflare had to stop collaboration from exposing information someone was not allowed to see, so it rebuilt the platform with security designed in from the start.

Early access: what the README warns about

The GitHub README marks this repository as version 2, a complete rewrite of version 1, and asks readers to treat it as an "early access" release. Version 2 is very capable but still has many rough edges, the README says, and the team knows about them and is working on them.

Weigh that before committing a team to it. The README also lists unfinished items, such as self-hosting on workerd, covered under deployment below.

How does Cloudflare OS keep API keys away from agents?

Every agent and app in Cloudflare OS starts with access to nothing, and a service-specific Worker called a Gatekeeper holds the credential, so neither the agent nor the code it writes ever sees the key. Cloudflare Access decides who can get into Cloudflare OS at all, and once someone is in, a Gatekeeper enforces policy for each service.

Cloudflare says people who start using AI at work often ask first for API keys to company systems. Handing keys to people and agents, it says, is dangerous and does not scale.

Why API keys and MCP alone fall short

An API key often grants broad, long-lived access that is hard to limit, share safely or audit. An MCP server can hold the credential instead and offer a set list of tools, so the agent never gets the key.

Controlling tools is only the first step, Cloudflare says. An agent can still gather data from several systems in one place, pass it to a destination with looser rules, or publish it in an app to a viewer who may not be allowed to see the source, so permissions have to follow the data onward instead of stopping at the first read.

Cloudflare OS also works with MCP servers an organization already runs, through MCP Server Portals. MCP Specification 2026-07-28: Sessions Removed covers the protocol itself, and Anthropic Cybersecurity Tests: Claude Broke In covers an incident in which a model pulled application and infrastructure credentials out of a real company.

Agents start with access to nothing

Inside Cloudflare OS, every agent and app begins with no access to any resource, while Cloudflare Access controls who can enter in the first place. An agent can request a specific resource, and the person can approve or refuse.

The README calls that grant an introduction. You introduce a GitHub repository by pasting its link or choosing "add resource" in the UI, and an agent can ask for an introduction itself. Most agent tools work the other way: MCP servers are configured in advance, and broad access is open in every chat.

The agent's code receives a granted resource as a typed binding. Cloudflare gives this example:

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

Here, env.PROJECT represents permission to use one resource under one policy. Generated server code runs in a Dynamic Worker with general outbound networking turned off, and client code is kept in a sandboxed frame in the browser, so neither side can reach the Internet except through capabilities the operator grants explicitly.

How a Cloudflare Gatekeeper governs actions

A Gatekeeper is a Worker built for one external service and placed between Cloudflare OS and that service. It knows the service's API, its resources and the operations on them.

Cloudflare's example is GitHub, where handing an agent a whole account is probably too much. A Gatekeeper can restrict an agent to one repository, let it read issues while keeping source code closed, hide chosen fields, cap request rates, and require a person's approval before any pull request merges.

All the agent and its apps see is a small TypeScript API. Behind it, the Gatekeeper handles OAuth, keeps the credential, applies the policy, logs each read, and sits between the agent and any action that changes something outside.

The repository comes with packages for eleven services, including GitHub, Google, Slack, Notion and Confluence. Many of them need OAuth client credentials from the service, and the README warns that providers often make these hard to get.

Approval is asynchronous so the agent keeps moving: when an action needs sign-off, the Gatekeeper simulates the result locally and the agent carries on, queuing more actions for a person to approve or reject later, together or one at a time. Waiting on synchronous approval, the README says, leaves agents stuck and nudges people toward auto-approve settings.

Policy follows what the agent has seen

Every resource an agent looks at is logged, and that log stays attached to the agent's work. When someone else opens the workspace, talks to the agent or views its output, the Gatekeepers check that person's access to each logged resource.

In Cloudflare's example, an agent reads a sensitive data-warehouse table and builds a live dashboard from it. Publishing the dashboard must not quietly give the table to people with no right to see it.

The log also shapes what the agent may do next. Having read sensitive data can block the agent from writing to certain places, inviting collaborators, passing work to another agent or making outbound requests. Cloudflare's point is that people building apps or using agents do not have to get these checks right on their own.

Why does every Cloudflare OS app run as a Worker?

Every Cloudflare OS app is a full-stack application whose server side loads on demand as a Dynamic Worker, a lightweight V8 isolate, so it gets its own runtime with no dedicated server or container. A Durable Object Facet gives each app its own SQLite database, and the browser talks to the server over Cap'n Web.

A Worker is how Cloudflare runs code without keeping a server running for it. In Cloudflare OS, any single file can be a small application an agent writes for one person, one project or one team, and it stays private until you share it, the way you would share a document.

An isolated Dynamic Worker with its own database

The agent writes both halves of an app: client code that renders the interface in the browser, and server code that holds state and defines behavior. Cloudflare loads the server only when it is needed, as a Dynamic Worker running as a Durable Object Facet, and says it built both features for this project.

The facet gives the app its own SQLite database, separate from the runtime that manages it. The README adds that every workspace is its own Durable Object and every gadget, its term for a private instance of an app, runs in a Dynamic Worker Facet.

The browser client calls the server through Cap'n Web, Cloudflare's open source object-capability RPC system, as if a server method were an ordinary JavaScript function. The agent can call the same method too.

Share the app, or share a blueprint

An app can be shared for real-time work on the same state, or as a blueprint that gives each person their own copy. Real-time collaboration works, the README explains, because every gadget is backed by a Durable Object.

A blueprint copy carries the original app's code but none of its SQLite data, conversation history, credentials or connected resources, so each new app starts with its own state and resources. The README contrasts an office template, which is only content, with a blueprint, which specifies a whole application. The benefit Cloudflare names is that teammates can change a shared app themselves with AI instead of filing a feature request.

Any model, routed through Cloudflare AI Gateway

Cloudflare OS works with any model, and every inference call passes through Cloudflare AI Gateway. That gives the organization one place to decide which models are available and which model handles each job.

Every request is linked to the person, team or workspace that sent it. Administrators can see where inference money goes, set budgets and rate limits, and decide what happens when a limit is reached. The README says it supports many major model providers and self-hosted models, with more on the way.

How do you deploy Cloudflare OS from GitHub?

Cloudflare released two repositories: the Cloudflare OS core and cloudflare-os-starter, an example deployment modeled on how Cloudflare runs it. To try it, install pnpm, run pnpm run-local and open localhost:8787; to run it for your organization, use the online deploy flow or the starter.

On 2026-09-30 the cloudflare/cloudflare-os page showed 10.2k stars, 1.3k forks and 846 commits on main. The starter repository uses the core without patching it and is where configuration, custom UI, internal integrations, analytics and deployment pipelines go.

Run Cloudflare OS locally with pnpm

To start quickly, install pnpm, run pnpm run-local and open http://localhost:8787. That runs the full stack locally on wrangler and workerd, with your data stored in a .wrangler subdirectory.

The README says this setup is not for production, only a fast way to see what the product does. Some suggested prompts work right away, such as making slides for a customer meeting or building a collaborative whiteboard app. Others need an integration first: an issue dashboard for a GitHub repo needs GitHub, and fixing typos in a Google Doc needs Google.

Deploy to your account or start from the starter repo

According to the blog, you deploy Cloudflare OS into an account you own, so your own Access policies, AI Gateway setup, data and integrations apply. The README points to an online deploy flow at os.cloudflare.app/deploy. For setups that add Gatekeepers or change code, there is the starter repository, which the blog says gets it running in a few minutes.

Cloudflare's own deployment is shaped around its systems, terminology and policies. The design lets you change the interface, add internal Gatekeepers and build organization-specific features without touching the core.

Presidio and Happy Cog, Cloudflare's strategic partners, will help organizations customize and roll it out. Cloudflare says they can help curate shared skills, build custom interfaces, connect internal systems and set up security, model and cost controls.

What is still missing from the open-source release

The README marks self-hosting on your own servers with workerd as COMING SOON, with documentation and tooling still in progress. Cloudflare also says it is working on a fully managed version in the Cloudflare dashboard, containers for development workflows, and workspaces inside Slack and other chat tools, all of them plans rather than shipped features.

Outside contributions are not being sought: the project accepts only small, easily verified fixes of about a dozen lines, closes low-value pull requests such as typo fixes, and sends larger ideas to a discussion. The README says this policy may change. For a team weighing Cloudflare OS now, it is an Apache-2.0 licensed platform whose own README asks you to treat it as early access, with self-hosting unfinished and outside contributions limited.