cloudflare/cloudflare-os

cloudflare/cloudflare-os

Description: Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems.

Language: TypeScript

License: Apache-2.0

Stars: 3524

Forks: 234

Open issues: 15

Created: 2026-04-15T22:22:53Z

Pushed: 2026-08-06T04:15:47Z

Default branch: main

Fork: no

Archived: no

README:

Cloudflare OS: An AI productivity environment

Cloudflare OS is an "operating system" for AI productivity originally developed for use inside Cloudflare. A large portion of Cloudflare's workforce -- from engineering to sales and everything in between -- uses Cloudflare OS every day to help them do their jobs.


This is not a traditional computer operating system. We use the term "operating system" in two senses:

• An operating system for *the company* to be productive with AI, in a way that is safe, so that the security team can sleep at night.
• An operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads.

Cloudflare OS provides three things in particular:

1. An agent chat UI where you can ask agents to do tasks, preloaded with knowledge about how your company operates. 2. Sandboxed application development, so that you can ask agents to build "gadgets" (small personal apps) and safely share what you've built with others. 3. A security framework, called Gatekeepers, that applies guardrails to both agents and apps such that non-technical users can safely "go nuts" and nothing bad will happen.

We are making Cloudflare OS open source so that others can copy it and customize it for their own company. The idea is not that your company uses Cloudflare OS, but rather that you make it "*Your Company* OS".

Quick Start

To quickly run Cloudflare OS locally, install pnpm, then do:

pnpm run-local

Then visit: http://localhost:8787

This runs the whole stack locally on wrangler and workerd. This is not meant for production use, but is a quick way to see what the product does.

Alternatively, you can deploy to your Cloudflare account.

(More options at the end of this readme.)

What to try

Try prompts like:

• "Make slides for my upcoming meeting with a customer." (This will use the built-in slides blueprint.)
• "Make a collaborative whiteboard app." (This will create a new app from scratch.)
• "Make a tic tac toe game." followed by "I'll be X and you be O. I've made my first move. Your turn."
• "Make an issue dashboard for this GitHub repo." (Attach a repo; requires that the GitHub integration is configured.)
• "Fix the typos in this Google Doc." (Attach a doc; requires that the Google integration is configured.)

WARNING: Early access

Cloudflare OS is in a state of heavy development. This repository is actually version 2, a complete rewrite taking what we learned from version 1 and putting it on a new foundation.

As of the August 2026 release, Cloudflare OS v2 is very capable, but still has many rough edges. We know, and we're working on it. For now, consider this an "early access" release.

Overview: What is Cloudflare OS really?

Gadgets: A new way of thinking about software

Cloudflare OS is more than just another chatbox with connectors. The system revolves around a new approach to software, where every user runs their own copy of the productivity apps they use.

When you create a slide deck in Cloudflare OS, you are not calling out to some SaaS software running in the cloud. The system creates a *private instance* of the slide deck software *just for you*. We call this a "gadget". This instance runs in a separate sandbox from everyone else's slide decks.

This has two profound effects: 1. It's impossible for the slide deck app to have a security bug that leaks your slides to an attacker. The Cloudflare OS sandbox controls all access to your private instance of the app. 2. If you want, you can freely modify the code. If the slide deck app is missing a feature you need, you can just ask your agent to add it. And because of point 1, it's totally safe to do so.

This is a big departure from the last 25 years of cloud architecture and "Software as a Service", but we think AI has changed the equation. When any user is capable of prompting an agent to add the features they need, the centralized model of software stops making sense.

Gatekeepers: A capability-based security layer

Gatekeepers are like supercharged MCP servers.

When you introduce an agent or Gadget to an external resource, a Gatekeeper is created to manage that access. The Gatekeeper is a piece of software specific to each external service which moderates a Gadget's connection to that service. It:

• Provides a clean Cap'n Web API to the service (wrapping whatever API the service provides natively).
• Handles authorization (e.g. via OAuth).
• Enforces narrow access to only the specific resource the user intended.
• Logs every action the Gadget (or agent) performs, for your review.
• For any action which has side effects, provides the human user an opportunity to approve or deny the action ("human in the loop").

On the last point, Gatekeepers implement a significant advancement in the state of the art. Traditionally, human-in-the-loop setups require the human to approve actions *synchronously*. When the agent wants to do something, it has to *stop* and wait for said approval before it can continue. This is annoying: you give your agent a task, then walk away and get a coffee, only to come back and find the agent got stuck on an approval on the first step and has made no progress. As a result, people often give in and set their agents to "auto-approve", or --dangerously-skip-permissions, which is, obviously, unsafe.

Gatekeepers provide a better way: When the agent (or Gadget) performs an action that requires approval, the Gatekeeper will *simulate* the outcome locally, allowing the agent to proceed and queue up more actions. The Gatekeeper tells the agent that the action completed, and if the agent tries to read back the results, the Gatekeeper gives it simulated results. Once the agent is done, the user may approve or reject the actions in bulk, or one-by-one, but either way, they can do it later, when it is convenient.

Logistically, each Gatekeeper is implemented as a separate...