Cloudflare has released Cloudflare OS as open source, a platform the company describes as an “operating system” for productivity with artificial intelligence. The name can be misleading: it isn’t meant to compete with Linux, Windows, or macOS. Its goal is to provide an environment where employees and AI agents can build applications, query corporate resources, and take actions under an isolation model, specific permissions, and human approval. Cloudflare itself says a significant share of its workforce already uses this technology internally.
Cloudflare OS in 20 seconds
- Cloudflare has released the code for an AI platform originally built for internal use.
- Users can ask agents to build small applications, called Gadgets.
- Gatekeepers limit which external resources each application or agent can use.
- Sensitive actions can be left pending human approval.
- Cloudflare OS v2 remains in early access, and some parts of its self-hosted deployment are still awaiting documentation.
The proposal is especially interesting because it tackles a problem that shows up once AI agents stop being limited to answering questions. A chatbot that generates text carries a relatively manageable risk. An agent capable of reading repositories, modifying documents, querying internal applications, or taking actions needs a far more precise permissions system.
Cloudflare OS tries to build that environment around three main components: Agent Workspaces, Gadgets, and Gatekeepers. The operating-system analogy comes precisely from this separation between users, applications, resources, and permissions.
Gadgets: small apps AI can create and modify
One of the more distinctive concepts in Cloudflare OS is the Gadget.
The idea moves away from the traditional software-as-a-service (SaaS) model, where a centralized application is used simultaneously by thousands of users.
In Cloudflare OS, each user can have their own instance of an application.
For example, someone might ask:
Create a collaborative whiteboard app.The agent generates the corresponding Gadget, and that application runs inside its own isolated environment.
Another request might be:
Make slides for my upcoming meeting with a customer.In this case, Cloudflare OS draws on one of its Blueprints, templates that don’t just hold information but the code of a full application.
The difference appears when a user needs something the application doesn’t yet do. Instead of filing a request with a developer, they can ask the agent to modify the code of their own copy.
Cloudflare believes AI can make viable a model where every employee has customized versions of relatively small tools.
The architecture tries to keep that freedom from turning into a security problem.
Each Gadget runs inside an independent sandbox. The server-side code runs through a Dynamic Worker with no direct, general internet access. To communicate with external services, it needs resources that have been explicitly authorized.
The client also runs inside an isolated iframe, restricted through Content Security Policy and the sandboxing features available in the browser.
The project sums up the model with a simple idea: a newly created application does not automatically get access to company systems.
That behavior matters especially when the code may have been written automatically by a model.
Gatekeepers: specific permissions for agents and applications
The second piece is the Gatekeeper.
Cloudflare compares them to more tightly controlled Model Context Protocol (MCP) servers. Their job is to sit between the agent or Gadget and external services.
When a user wants to let an agent work with, say, a specific repository, access goes through a Gatekeeper.
This component handles several tasks:
- authentication and authorization, including OAuth when relevant;
- limiting access to the specific resource the user authorized;
- logging the operations performed;
- providing an API for the agent;
- requesting human approval for actions with external effects.
This last feature is one of the technically more striking parts of the project.
Agent systems often run into a problem when they need human approval. If the agent tries to run a sensitive operation, it can end up stalled waiting for someone to click “approve.”
That works fine while the user is sitting in front of the screen. It loses much of its usefulness when the goal is to let the agent keep working for several minutes on its own.
Cloudflare proposes a different mechanism.
The Gatekeeper can locally simulate the outcome of an action that’s still awaiting authorization. The agent receives a simulated response and can keep working on that assumption.
If it later needs to check the result of that action, it again receives simulated information.
Once the work is done, the user can review the pending operations and approve or reject them individually or in bulk.
This separates two moments that are normally tied together: the agent’s reasoning and the actual execution of actions with real external consequences.
The approach doesn’t eliminate the risk, either. If the user approves every operation without thinking, the control loses much of its value. But it avoids a situation where the only practical alternative is granting standing permissions or reaching for the equivalent of skipping the confirmations altogether.
Agents shouldn’t inherit all of a user’s permissions either
Cloudflare OS also adopts a capability-based security model.
Every agent and every Gadget starts with no access to external resources.
Even if the organization has set up corporate integrations, those credentials don’t automatically become available to any conversation.
The user has to explicitly “hand” the resource to the agent.
That can happen, for instance, by providing the link to a specific repository. The agent then gets access to that resource through the corresponding Gatekeeper, rather than inheriting blanket permissions over every repository available to the user.
The approach tries to apply least privilege to agents.
The difference matters compared with setups where an MCP server is added globally to the environment and all of its tools become available during any session.
Cloudflare argues that an agent shouldn’t simply be treated as just another user. It should act under a person’s responsibility, but with its own restricted permissions.
In its analogy with a traditional operating system, Cloudflare draws these parallels:
| Traditional operating system | Cloudflare OS |
|---|---|
| Kernel | Workshop backend |
| Drivers | Gatekeepers |
| Shell | Workshop frontend |
| Processes | Gadgets |
| Executables | Blueprints |
| Users | Users |
| ACLs | Shared permissions |
| — | Agents |
The comparison has its limits, but it helps explain why Cloudflare chose the word OS.
It isn’t trying to manage CPU, memory, and devices the way Linux does. It’s building a layer meant to connect people, agents, applications, and corporate resources while keeping security boundaries between them.
Built on Workers, Durable Objects, and workerd
Cloudflare OS makes heavy use of technologies the company already relies on in its execution platform.
Each workspace runs as a Durable Object. Gadgets use Dynamic Worker Facets, and Gatekeepers are also plugged into the workspace to manage access to remote resources.
The project also uses Cap’n Web RPC for client-server communication within Gadgets.
That choice has another consequence: the applications it creates come with an interface agents themselves can use.
A user might first ask:
Create an issue dashboard for this repository.and then ask the agent to work with the generated application without having to specifically build an MCP server for it.
Cloudflare calls the approach its agent uses Code Mode: it generates small snippets of code and runs them to get tasks done.
The platform isn’t locked into a single model provider, either. The project says it can work with different large language models (LLMs), including self-hosted models, though exact compatibility depends on the configuration.
It can be tested locally
Cloudflare has published the project along with instructions for running it locally.
After installing pnpm, the basic procedure is:
pnpm run-localThe interface is then available by default at:
http://localhost:8787This mode uses wrangler and workerd, and it’s meant mainly for testing the project, not for running a production install. Local data is stored inside the .wrangler directory.
There’s also a procedure for deploying Cloudflare OS inside a Cloudflare account.
There’s an important nuance here about the platform’s independence.
Cloudflare explains that being built on Workers doesn’t necessarily mean Cloudflare OS always has to run on its infrastructure. workerd, the Workers runtime, is also open source and can run on self-hosted servers.
However, as of this article’s August 2026 publication, the instructions and tooling for deploying Cloudflare OS on workerd on self-hosted servers are still marked “Coming Soon”.
So that option is part of the project’s architecture, but it doesn’t yet have the same documented path as deployment inside a Cloudflare account.
An open project, but still in early access
Cloudflare isn’t presenting the current version as a finished product.
The company identifies this August 2026 release as Cloudflare OS v2, a complete rewrite based on lessons learned from the first version.
The repository considers it functional enough to experiment with, but acknowledges there are still plenty of rough edges and explicitly uses the term early access.
The approach to contributions is also worth noting.
Even though the code is open, Cloudflare isn’t currently looking for large external contributions. The project explains that AI has lowered the cost of writing code, while reviewing changes, maintaining quality, and keeping the product coherent still requires human work.
It does accept small, easily verifiable fixes, and recommends using the repository’s discussions for larger-scale proposals.
Beyond the name, the interesting part of Cloudflare OS is probably the problem it’s trying to solve.
Companies are moving from employees who query chatbots to agents that can execute code and act on corporate systems. In that scenario, simply connecting a model to every available tool is no longer enough.
Someone has to decide which agent can access which resource, isolate the code it generates, log its actions, and set when a person needs to step in.
Cloudflare OS proposes an architecture for organizing those relationships. It’s still at an early stage and several pieces are still evolving, but its Gadgets, Gatekeepers, and permissions model point toward an interesting answer to a question more and more systems and security teams will have to face: how to let agents do real work without handing them the full keys to the infrastructure.
Frequently Asked Questions
What is Cloudflare OS?
Cloudflare OS is an open-source environment for working with AI agents, building small applications, and connecting them in a controlled way to corporate resources. Despite its name, it isn’t a conventional operating system like Linux or Windows.
What are Gadgets in Cloudflare OS?
Gadgets are individual applications that can be created and modified with the help of AI agents. Each instance runs in isolation and doesn’t get general access to the internet or corporate resources by default.
What are Gatekeepers for?
Gatekeepers control the connection between agents or Gadgets and external services. They handle authorization, restrict which resources are available, log operations, and can require human approval for actions with external effects.
Can Cloudflare OS be installed on self-hosted servers?
The architecture supports workerd, the open-source Workers runtime, and the project can be tested locally. However, in the version released in August 2026, the documentation and tooling specific to a production deployment on self-hosted servers are still listed as pending.
