Cloudflare Open-Sources an 'OS' Where Every User Gets Their Own AI-Built App

Cloudflare has open-sourced Cloudflare OS, an internal AI productivity environment that a “large portion” of its own workforce uses daily, and the company is publishing the whole thing on GitHub under a “make it Your Company OS” framing. The repo is version 2, a complete rewrite built on Cloudflare Workers, and it ships with a warning that it is “early access” with “many rough edges” as of an August 2026 release.

The interesting part is not the chat UI. It is the architecture underneath, which quietly argues that the last 25 years of software-as-a-service were a detour and that AI agents make a different model viable.

Every document is its own app

Cloudflare OS revolves around “Gadgets.” When you make a slide deck, you do not call a shared SaaS app. The system spins up a private instance of the slide deck software just for you, running in its own sandbox. Cloudflare’s pitch: it becomes impossible for a bug in the deck app to leak your slides, because the sandbox controls all access. And because of that isolation, you can freely ask an agent to modify the code. Missing a feature? Prompt for it.

That is a real departure from multi-tenant cloud software, and it is only plausible because the cost of writing and patching a small app has collapsed. Cloudflare says the expectation is that AI writes the code, tests it, and debugs errors. You can choose your LLM, and the company claims its coding agent “often performs better and faster with fewer tokens” than a general-purpose agent because the platform is tightly integrated.

Take the performance claim with salt. It is Cloudflare grading its own homework, with no benchmark published in the readme. But the structural claim is more defensible: because every Gadget’s client and server must talk over Cap’n Web RPC, every app automatically exposes an API an agent can call. No MCP server to write, no custom agent loop to wire up. That is a genuine design decision, not marketing.

Gatekeepers are the part worth stealing

The most consequential piece is the security layer, called Gatekeepers. Cloudflare describes them as “supercharged MCP servers”: each one wraps an external service, handles OAuth, enforces narrow access to the specific resource the user intended, logs every action, and inserts a human approval step for anything with side effects.

The novel bit is how they handle that approval. Traditionally, human-in-the-loop means the agent stops and waits. You give it a task, walk away for coffee, and come back to find it stuck on step one. So people flip on auto-approve or --dangerously-skip-permissions, which is exactly the unsafe outcome the guardrail was meant to prevent.

Gatekeepers instead simulate the outcome locally. The agent is told the action completed, and if it reads back the results, it gets simulated results. It keeps working and queues up more actions. The human approves or rejects in bulk, later, when convenient. This is a clever inversion: it preserves the safety check while removing the latency that pushes users to disable it. Whether the simulation is faithful enough to avoid confusing agents in edge cases is an open question the readme does not answer.

Gatekeepers simulate the action, tell the agent it succeeded, and defer the human’s approval until later. It is a real answer to the auto-approve problem.

The OS analogy is more than a metaphor

Cloudflare maps its stack onto operating-system concepts with unusual literalness. The “kernel” is the workshop-backend package. Gatekeepers are device drivers. Gadgets are processes. Blueprints, which specify a whole application rather than just content, are executables. And agents? Cloudflare marks them with a ”???” in its own comparison table, then argues they are a category traditional OSes never had to manage.

The argument: agents cannot simply be treated as users. They must be accountable to a human while holding their own restricted permissions, and they do work by writing and executing code on the fly. Cloudflare says the right security model for that is capability-based security, not access control lists. It is a pointed claim, and one that lands harder coming from the team that built Workers.

The dependency stack is worth naming, because it tells you where the lock-in lives. Every workspace is a Durable Object. Every Gadget runs in a Dynamic Worker Facet. Gatekeepers install facets into each workspace. Cloudflare says Dynamic Workers, Facets, and several other runtime features were added specifically to support Cloudflare OS. That is a lot of new surface area, and early adopters will be the ones finding the sharp edges.

What it means for AI builders

Two things stand out. First, the sandbox-per-user model is a template. If agents can write and patch software cheaply, the multi-tenant SaaS assumption that one codebase serves everyone gets weaker, and Cloudflare is betting its runtime can host the alternative. Second, Gatekeepers are a concrete proposal for the approval problem that every agent framework is currently fumbling. That idea is portable, and it does not require running on Cloudflare.

The escape hatch matters too: workerd, the Workers runtime, is itself open source, so Cloudflare OS can run on your own servers. That softens the platform-lock concern, at least in principle.

The open question is whether “every user runs their own app” survives contact with real IT departments. Thousands of AI-written gadgets, each with its own permissions and audit log, is a governance load that most security teams have not modeled. Cloudflare says the security team can sleep at night. It has not yet shown the rest of us the logs.