Cloudflare OS: An AI Productivity Environment, Open Sourced
A deep dive into Cloudflare OS, the open-source AI productivity environment from the Workers team, covering Gadgets, Gatekeepers, Blueprints, and capability-based security.
Published on • August 9, 2026
AI Assistant

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 it every day to help them do their jobs.
The “operating system” label is intentional, and it’s used in two senses:
- An operating system for the company to be productive with AI in a way that is safe, so the security team can sleep at night.
- An operating system for AI workloads, analogous to how a traditional OS manages compute workloads.
Now Cloudflare has made it open source so that others can copy and customize it for their own company. The idea is not that your company uses Cloudflare OS, but that you make it “Your Company OS”.
What Cloudflare OS Provides
Cloudflare OS delivers three things in particular:
- An agent chat UI where you can ask agents to do tasks, preloaded with knowledge about how your company operates.
- Sandboxed application development, so agents can build “gadgets” (small personal apps) that you can safely share with others.
- A security framework called Gatekeepers that applies guardrails to both agents and apps, so non-technical users can safely “go nuts” and nothing bad will happen.
Quick Start
To run Cloudflare OS locally, install pnpm, then run:
pnpm run-local
Then visit http://localhost:8787. This runs the whole stack locally on wrangler and workerd. It’s not for production use, but it’s a quick way to see what the product does. Alternatively, you can deploy to your Cloudflare account.
Some prompts worth trying:
- “Make slides for my upcoming meeting with a customer.” (Uses the built-in slides blueprint.)
- “Make a collaborative whiteboard app.” (Creates 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.” (Requires the GitHub integration.)
- “Fix the typos in this Google Doc.” (Requires the Google integration.)
Early Access Warning
Cloudflare OS is in a state of heavy development. The repository is actually version 2 — a complete rewrite that takes the lessons of version 1 and puts them on a new foundation. As of the August 2026 release, it is very capable but still has rough edges.
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:
- 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.
- You can freely modify the code. If the slide deck app is missing a feature, 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 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. Each Gatekeeper is software specific to a service that moderates a gadget’s connection to it. 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 with side effects, gives the human user a chance to approve or deny it — “human in the loop”.
Gatekeepers also implement a significant advancement in human-in-the-loop UX. Traditionally, HITL setups require the human to approve actions synchronously — the agent has to stop and wait for approval. That’s annoying: you give your agent a task, walk away for coffee, and come back to find it stuck on the first step. People often give in and set agents to “auto-approve”, or --dangerously-skip-permissions, which is unsafe.
Gatekeepers do better: when an agent performs an action requiring approval, the Gatekeeper simulates the outcome locally, letting the agent proceed and queue up more actions. It tells the agent the action completed, and feeds simulated results if the agent reads back. Once the agent is done, the user approves or rejects the actions in bulk or one-by-one, whenever it’s convenient.
Each Gatekeeper is implemented as a separate Worker, and the repository ships several interesting ones (GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Email, Home Assistant, Slack, Spotify, ZoomInfo) that you can deploy with your own OS instance.
Think of an Office Suite
The basic user experience is something like an online office suite — Google Docs or MS Office. But instead of a fixed set of file types (document, spreadsheet, slide deck), each file — or gadget — is potentially its own custom application, written by AI to serve exactly your needs.
Just like office docs, gadgets are private by default but can be shared securely to collaborate with your team or friends. You can have thousands of them and create them on a whim. You can start from templates — called “Blueprints” — but where an office template is just content, a Blueprint specifies a whole application. And you can create new Blueprints from your own gadgets and share them with others.
It Kind of Is an Operating System
The OS terminology isn’t entirely marketing. Cloudflare OS is actually analogous to an OS on a technical level:
| Normal OS | Cloudflare OS |
|---|---|
| kernel | packages/workshop-backend |
| device drivers | packages/gatekeeper-* |
| shell | packages/workshop-frontend |
| processes | gadgets |
| executables | blueprints |
| users | users |
| ACLs | shared permissions |
The “kernel” lives in the workshop-backend package, which connects users to programs and devices (Gadgets and Gatekeepers) while implementing security by sandboxing applications and enforcing access control. Gatekeepers are like device drivers: they connect users and agents to external services.
There is one thing traditional OSes don’t manage today but Cloudflare OS does: AI agents. AI agents cannot simply be treated as users. They must be accountable to a human user while having their own restricted permissions. Agents do work by writing snippets of code and executing them on the fly. The ideal security model for this is capability-based security, not access control lists.
Built on Workers, by the Workers Team
Cloudflare OS is built on Cloudflare Workers, making heavy use of Durable Objects, Dynamic Workers, and Facets. Every workspace is its own Durable Object, every Gadget runs in a Dynamic Worker Facet, and Gatekeepers install facets into each workspace to manage access to remote services.
Cloudflare OS is built by the people who built Workers itself. It uses cutting-edge features of the Workers Runtime — in fact, Dynamic Workers, Facets, and several other features were added to the runtime specifically to support Cloudflare OS. Studying the source is a great way to understand how the Workers Runtime team thinks Workers should be used.
Being built on Workers doesn’t mean Cloudflare OS can only run on Cloudflare. workerd, the Workers Runtime, is itself open source, and Cloudflare OS can run entirely on top of it on your own servers.
Key Features
General Multi-Purpose Agent
The Cloudflare OS coding agent is a fully multi-purpose agent that can perform arbitrary tasks. You don’t have to code with it — you can build Gadgets or just have the agent perform tasks directly. It’s a Code Mode agent: it performs tasks by writing and immediately executing snippets of code.
Build Apps with AI
While you can code a Gadget by hand, the expectation is that AI writes the code. The built-in coding agent builds whatever you ask, tests it, and debugs errors. You can choose your LLM — Cloudflare OS works with many major AI model providers and self-hosted models.
Because of the tightly-integrated and simplified nature of the platform, the Cloudflare OS coding agent often performs better and faster with fewer tokens than a general-purpose coding agent using the same underlying models.
Collaborate with AI
Every app built with Cloudflare OS automatically has an agent-friendly API. After you’ve asked AI to build the app, you can also ask AI to collaborate with you inside the app. No need to build an MCP server or integrate a custom agent loop.
This works because Gadget clients and servers communicate via Cap’n Web RPC. Cap’n Web is extremely low-boilerplate, which makes it easy for agents to work with, and it means the server necessarily exposes an easy-to-understand API an agent can call directly.
Real-Time Multiplayer
You can share a Gadget just like you’d share a document in an online office suite — give specific users access or create a share link. You’ll see collaborators’ actions in real time, because every Gadget is backed by a Durable Object, which makes real-time multiplayer collaboration easy. The coding agent implements it by default, without being asked.
Blueprints: Share Your Code
If you’ve created a Gadget that might be useful to others, but you don’t want to share the Gadget itself, you can share a Blueprint — essentially a copy of the code — allowing others to create their own copy of the Gadget.
Blueprints are a major change from cloud software tradition. Traditionally, if you create a web app to share, you host it on your server and users connect to it. Blueprints are more like mobile and traditional PC apps: every user runs their own copy of the software.
In the age of AI this is critically important. AI empowers individuals to build more than ever, but it’s still hard for an individual to maintain an online service — Blueprints eliminate that need. More importantly, allowing each user to run their own copy empowers them to change the software to meet their needs using AI. No feature requests, no begging the developer to prioritize. The end user can solve their own problems.
Sandboxed and Secure by Default
Each Gadget runs in a secure sandbox that prevents it from talking to the internet at all without your explicit consent:
- The server runs in a Dynamic Worker with internet access disabled. It can only communicate with specific external resources you’ve explicitly designated, via Workers Bindings.
- The client runs in a sandboxed iframe that can communicate with its server only via a Cap’n Web RPC session provided over
postMessage()to the parent frame. The iframe is otherwise blocked from the internet via Content-Security-Policy and iframe sandbox settings.
Capability-Based Access Control
Each agent and each Gadget has access to nothing by default — even if you’ve configured the Gadget Workshop with access to external accounts. Instead, you must introduce each agent or gadget to the specific resources it should access, e.g. by pasting a GitHub repository link or clicking “add resource”.
This differs from most agent harnesses, where MCP servers are configured upfront, making broad access ambiently available to the agent in every chat. Capability-based introductions keep each agent restricted to only the access it actually needs for the job at hand.
Getting Started
To deploy to your own Cloudflare account, use the online flow at https://os.cloudflare.app/deploy, or check out the deployment starter repo at https://github.com/cloudflare/cloudflare-os-starter for more sophisticated deployments.
To run locally, install pnpm and run pnpm run-local, then visit http://localhost:8787. Your data will be stored in a .wrangler subdirectory.
For production-grade deployment on your own servers with workerd, the tooling is “coming soon” — the underlying support already works, but Cloudflare is still writing docs and tooling for a smooth workerd deployment experience.
Contributing
At this time, Cloudflare is not seeking outside contribution. AI has made writing code easy; the hard part today is reviewing it and keeping quality high. External code contributions “donate” the easy part of the job while creating more of the hard work.
Cloudflare will happily accept small, trivially-verified PRs that fix a problem, but asks that you refrain from low-value PRs (e.g. typo fixes) or PRs longer than a dozen lines. For big ideas, open a discussion on the repository.
Credits
Cloudflare OS has too many open source dependencies to list, but a few do particularly heavy lifting:
- Pi (specifically
pi-agent-core) made it easy to support every LLM provider with one API. - Monaco embeds a beautiful text editor for those who still look at the code.
- Yjs syncs code changes between clients and agents and replays histories.
- Vite makes the development loop pleasant.
Conclusion
Cloudflare OS is a genuinely new take on AI productivity software. By combining private, sandboxed, AI-written applications (Gadgets), a capability-based security layer (Gatekeepers), and shareable app templates (Blueprints), it moves beyond the chatbox-with-connectors model toward something that actually behaves like an operating system for the AI era.
The decision to open source it — and to build it on the open-source workerd runtime — means any organization can deploy, customize, and own its own AI productivity environment. Whether you’re a team at Cloudflare, a startup, or an enterprise, the core question is the same: what would your company OS look like?