Every "file" is a standalone app with its own sandbox and its own database

Traditional office suites hand you a fixed set of file types: docs, sheets, slides. Cloudflare OS ditches that premise entirely. Every "file" can be its own complete application, written on the fly by an agent for you, for a project, or for a team.

In the repo, this is called a gadget; the public blog post translates it as "app." Same thing. It's not a prototype, and it's not a half-finished thing you have to export and deploy somewhere else. Each one is a complete full-stack application: frontend code, backend code, APIs, and persistent state. Private by default, shareable like a document.

How does it give everyone their own instance without burning money? Three pieces fit together:

The first two are features Cloudflare added to the Workers runtime just this spring. The repo README is explicit about where they came from: these features were added to the runtime specifically to make Cloudflare OS possible, and more are on the way.

Cap'n Web comes with a free bonus

The third piece has a side effect, and it's the most elegant part of the whole design. Because the frontend has to call the backend through a well-defined method interface, that same interface is naturally callable by an agent.

That little tool you built for yourself? An agent can use it to do work for you while you're away. No need to write a separate MCP server, no need to bolt on another agent loop. It comes free. The official architecture diagram puts it right in the middle: whatever the UI can do, the agent can do.

Two ways to share: use the same app together, or hand over the code so someone can make it their own

The first is sharing the app itself: everyone goes into the same app, the same SQLite database. Changes are visible to everyone in real time, like collaborating in Google Docs.

The second is sharing a blueprint. The recipient gets a copy of the code and generates a brand-new app from it. None of the original app's data, conversation history, credentials, or connected resources carry over. From that point on, the two run independently.

The second mode is the important one. It means someone who gets your app can have their own AI modify it, instead of filing a feature request and waiting in your backlog.

The repo README takes this argument even further. For the past 25 years, the SaaS logic has been: I run the software on my servers, you connect and use it; if you need a feature, you have to beg for a spot on my roadmap. Blueprints are closer to the mobile-app or PC-software model: each user runs their own copy, and if they need something, their AI adds it. The README's argument is that while AI lets individual developers build far more than ever before, individually maintaining an online service is still hard — and blueprints remove "maintaining the service" from the equation entirely.

Gatekeeper: agents start with zero access, and approval isn't handing over a key

Around February, a colleague from Cloudflare's sales team went to the company CIO asking for API keys — a lot of them. This person had used AI to assemble a "super app" that claimed it could transform the entire marketing team. One thing stood in the way: production credentials for a dozen of the company's core business systems, plus admin access to a deployment pipeline.

This is the wall every company runs into when rolling out AI. If AI can't touch the systems people actually work in, it's basically useless. But letting it in means handing over keys — and keys are broad, long-lived, hard to revoke, and impossible to audit.

MCP was already a step forward: the agent doesn't hold the keys directly; an MCP server holds them and exposes a defined set of tools. But the blog post zeroes in on MCP's blind spot:

MCP only tells us which tools an agent can call. It doesn't tell us which underlying resources it has actually seen.

Cloudflare Blog, "Cloudflare OS: An Open Platform for Agents, Apps, and Work"

An agent can easily combine information from several systems, move it somewhere less carefully guarded, or leak it through the apps and artifacts it creates to people who have no business seeing the raw data. So authorization can't stop at the front door. It has to govern where data can flow next.

That's what Gatekeeper is for. It's a Worker that sits between Cloudflare OS and an external service — one per service — and understands that service's APIs, resources, and possible operations. It does four things: holds the credentials, enforces policy, records what's been read, and intercepts every externally visible side effect.

Layer one: you start at zero, and approval gets you a scoped pass

The door into Cloudflare OS is managed by Cloudflare Access. Once inside, every agent and every app starts with zero permissions. An agent can request access to a specific resource, and you approve or deny it. When you approve, the code it writes gets something like this:

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

env.PROJECT is a capabilityThe original term is "capability." The difference from a key: a key is a string of characters that works for anyone who holds it. A capability is an object with its allowed actions baked in, and it can't be copied or handed to someone else. representing "use this specific resource under this specific policy." The credentials themselves are completely isolated from the agent and the code it writes — the code never touches a key.

The scoping can also be extremely fine-grained. The blog's example: handing an agent your entire GitHub account is clearly too broad. Gatekeeper can restrict it to a single repo, let it read issues but not source code, redact certain fields, apply rate limits, and require human sign-off before merging PRs.

Two more walls underneath: the app's server-side code runs in a Dynamic Worker with outbound network access disabled by default, and the frontend runs in a sandboxed iframe in the browser. Both sides can only reach the outside through the capabilities you explicitly granted. No other path exists.

The system remembers what the agent read — and checks viewers against that before they see anything

Controlling the initial read alone isn't enough. The blog gives an example that makes it instantly clear: an agent reads a sensitive table in the data warehouse and builds a live dashboard from it. Sharing that dashboard can't become a backdoor for sharing the underlying table.

Cloudflare OS's answer: log every resource an agent reads. These observation records travel with the agent and its artifacts. When someone else tries to open the workspace, chat with the agent, or view its output, the various Gatekeepers check one thing: is this person allowed to directly read what the agent read? If yes, they're in. If not, they're blocked.

The implementation in the repo goes further than the blog lets on

The blog just says "it checks." The full mechanism in docs/observers.md in the repo has three additional details the blog leaves out:

One: the recipient has to connect their own accounts first. When you share an app with a colleague, they have to pick one of their own accounts for each service the app depends on — their own Google, their own GitHub. The system then asks the Gatekeepers using their identity: can this person read these things? If not, they get a straight refusal. If they decline to connect an account, same result.

Two: once they're in as an "observer," your app's capabilities get clamped down. From the moment they become an observer, if the app tries to read anything the observer isn't allowed to see, that read is blocked on the spot and throws an exception. If you share your app with a colleague who has fewer permissions than you, your own app's read scope gets squeezed down to match theirs. There's only one way out: revoke their access.

Three: every time they open it, the check runs again. This guards against "they had access last month, but they changed roles since then."

The same observation records have a second job: governing outbound traffic. After reading sensitive data, an agent may be blocked from writing to certain destinations, pulling in new collaborators, delegating a task to another agent, or making certain external requests. What you read determines what you're allowed to do next.

Approval can wait: Gatekeeper fakes the issue first and lets the agent run to the end

Anyone who has used an agent tool with permission prompts knows this scene.

Traditional human-in-the-loop approval is synchronous: when the agent wants to do something with side effects, it stops and waits for you to click confirm. You assign it a task, walk away to refill your coffee, and come back to find it stuck on the first approval popup, having accomplished nothing. So people give up and set everything to auto-approve — or worse, add the skip-permissions flag. The README names it directly: --dangerously-skip-permissions. It's obviously not safe, but it beats sitting around waiting.

Gatekeeper's answer: don't actually do the thing, but make it look done.

The agent says "create an issue." Gatekeeper doesn't create one on GitHub. It queues the action for approval and hands the agent a temporary fake issue, so the agent believes it's done and can keep going. Labeling the issue, commenting on it, referencing it elsewhere — all of it works. The agent runs to completion without stopping. Later, when you have a moment, you review the batch: approve them all, approve them one by one, or reject them.

I checked the source: createIssue really does queue first, then returns a temporary ID

I pulled the repo and went through the GitHub Gatekeeper implementation. createIssue indeed first throws the action into submitActionForApproval, then immediately returns an issue object with a provisionalId to the caller. The code also shows the rendering format for these temporary IDs — the #~1 tilde-prefixed fake numbers, easily distinguishable from real ones.

The interface comment spells out the design intent:

Gatekeepers are encouraged to "simulate" the results of unapproved actions, i.e., the session API should behave as if all actions have already been applied. This allows the app to continue its work and enqueue further actions that depend on them.

cloudflare-os repo · packages/workshop-shared/src/gatekeeper.ts

The costs are in the comments too. Three of them.

One: simulation is "encouraged," not "required." Right after the passage above, the comment adds: Gatekeepers are not strictly required to simulate, and it's up to the Gatekeeper author to decide which actions are worth simulating. So the experience will vary from service to service.

Two: rejecting an already-simulated action can require restarting the entire app. Because state has already moved forward based on the fake result, an incomplete rollback will confuse the agent. The interface has a dedicated restart flag for exactly this. The code also handles cascading effects: if you reject the "create issue" action, every subsequent action that depended on that issue is rejected along with it.

Three: rollback is optional. A Gatekeeper may choose not to implement rollback. In that case, the system can only tell the user to undo it manually. The comment says "a high-quality Gatekeeper should implement it in almost all cases" — which, read backwards, means not all of them do right now.

Every model call and every dollar flows through the same gateway

All inference calls go through Cloudflare AI Gateway. The benefit is that there's a single place to decide which models are available and which tasks get routed to which model.

The reasoning is pragmatic: not every task deserves the most expensive model. Summarizing your unread email every morning doesn't need a frontier model. The CIO's post puts it even more bluntly — you can't have employees spending $20/hour to summarize their inboxes.

Every request is attributed to a specific person, team, and workspace. Admins can see where the money goes, set budgets and rate limits, and define what happens when those are exceeded.

The four providers supported out of the box in the repo

There's also a hook for local ollama. One TODO comment in the code is amusing: they'd like to add Claude Fable, but first need an admin toggle, because many companies prohibit it under zero-data-retention policies. The comment adds, "it's also kind of overkill for building these little apps."

The hosted version has another billing layer: each user gets a daily free allowance, defaulting to 100 model calls. After that, you either connect your own Cloudflare account and pay from your own AI Gateway balance (which must be above $2), or you're blocked. Self-hosted deployments have this layer disabled — no limits.

Inside Cloudflare for three months: 4,000+ apps built in the last 30 days, and a pile of junk

The first version of Cloudflare OS opened up to all employees in May 2026. Three months later, it's being open-sourced.

What did the saved time go toward? The CIO names territory mapping and proposal writing — sales tasks that used to be manual.

The miss first

Early on, they gave non-technical employees the exact same tool, just with a friendlier interface. The CIO's own summary is telling:

If you give everyone a workspace that's really good at writing code, you end up with way more code than you need.

Sam Rhea, CIO at Cloudflare

What appeared was a flood of vibe-coded apps in search of a problem to solve. That's a big part of why v2 pushed toward deterministic workflows: not every task needs a code-writing agent.

The CIO's own example, three generations side by side

Every morning he needs to see the IT helpdesk ticket queue and a few service metrics.

That last "zero" needs its premise spelled out: it holds because the dashboard has been written as code, the data is fetched directly through Gatekeeper, and loading it never touches a model. It's not "Cloudflare OS means zero token burn." The places he actually needs AI — like drafting replies to new tickets — are still embedded in the app, and those still burn tokens.

How they find out what to automate: a magic inbox for work nobody wants to do

This part has nothing to do with the product itself, but it's the most directly copyable thing in this entire post.

The problem: if you want to know which work in your company is worth automating, asking people "what would you like to automate?" usually produces useless answers. Cloudflare's approach is to ask a different question. They told the whole company: send the work you don't want to do to this magic AI inbox, and it will send you back the finished result.

There's no automated system behind the inbox. It's a small team of humans with AI tools, working through the requests one by one.

The genius is in the psychology. In the CIO's own words: for some reason, people don't like sending their vibe-coding ideas to something they think is an automated system, but they're very happy to dump the work they don't want to do.

After hundreds, then thousands of sessions, they manually sorted the requests and patterns started to emerge: which requests repeat, what data they need, what form of output people ultimately want. Once they could see it clearly, they turned it into skill files and context files, wired up the data sources, and locked down the output formats. Only when the material was sufficient did they put it on the platform for self-service.

The CIO describes the process as "painful," and says they kept almost shutting it down — but held on until they had enough material.

What to know before you dive in: this is an early version, and Gatekeepers have to be written by hand

Most of these come from the repo rather than the launch post, but they determine whether you should start now.

One: the README itself carries an "early access" warning. This repo is actually v2 — a complete rewrite informed by v1's lessons. Their words: it's surprisingly capable, but it still has rough edges; we know, and we're working on it.

Two: writing a Gatekeeper for a service is real engineering work. The repo ships 16 of them, covering Google, GitHub, Slack, Notion, Linear, Confluence, Supabase, Home Assistant, and other common services. I counted the lines of code for each:

In other words, for any in-house system without a ready-made Gatekeeper, someone has to write one — and at this scale, it's not an afternoon project. The good news: the repo includes two bridge packages, MCP and MCP Portal, so existing MCP servers can be plugged in directly. The catch is that you only get MCP-level control, not Gatekeeper's fine-grained policies.

Three: they don't accept external code contributions. The reasoning in the contributing guide is worth reading:

AI has made writing code easy. What's hard today is reviewing code, maintaining quality, and keeping the product coherent. Seen that way, external code contributions hand us the easy half of that work while creating more of the hard half.

cloudflare-os repo · CONTRIBUTING.md

They only accept small, instantly verifiable fixes; anything over a dozen lines gets closed with a link to this policy. Big ideas go in a discussion post.

Four: self-hosting on your own servers via workerd is still marked "coming soon" in the docs. It works technically — local dev mode runs on workerd — but the tooling and docs aren't complete. If you want to do it now, you'll be digging through low-level configuration yourself.

The official roadmap has three items: make Cloudflare OS a hosted product in the Cloudflare dashboard, add containers to the development workflow, and integrate workspaces into chat tools like Slack.

How to try it: one command locally, or one-click deploy to your Cloudflare account

The fastest path: run it locally. Install pnpm, run pnpm run-local, then open localhost:8787. The whole thing runs on your machine, with data stored in a local .wrangler directory. This mode isn't for production, but it's more than enough to get a feel for what the product actually is.

To deploy to your own Cloudflare account, there's an online flow: os.cloudflare.app/deploy. If you plan to customize deeply, use the cloudflare-os-starter template repo, which mirrors how Cloudflare itself deploys. The key design principle: consume the core, don't patch it. Configuration, custom UI, internal integrations, analytics, and deployment pipelines all live in your layer, so core upgrades don't clash with your changes.

The README offers a few starter prompts. Copied verbatim:

• "Make a set of slides for my customer meeting tomorrow." (Uses the built-in slides blueprint.)
• "Build a collaborative whiteboard app." (Built from scratch.)
• "Build a tic-tac-toe game." Then: "I'm X and you're O. I made my first move, your turn."
• "Build an issue dashboard for this GitHub repo." (Requires configuring the GitHub Gatekeeper first.)
• "Fix the typos in this Google Doc." (Requires configuring the Google Gatekeeper first.)

If you'd rather not do it yourself: Cloudflare's two strategic partners, Presidio and Happy Cog, offer deployment services — connecting internal systems, building out company context and skill libraries, and configuring security and cost policies.

In February, a Cloudflare sales colleague used AI to build a “super app” and went to the company CIO asking for API keys — several of them, plus production access to about a dozen core business systems. An AI that can’t reach the systems people actually use is useless, but reaching them means handing out keys.

The keys sit inside a small program called Gatekeeper — one per service — which gets credentials for you, enforces policy, logs everything the agent reads, and blocks any action with external side effects. You can get granular enough to mask certain fields, or require a human to approve before merging code.

Controlling first-time reads isn’t enough: if an agent reads a sensitive table in the data warehouse and builds a real-time dashboard from it, sharing that dashboard shouldn’t become a backdoor that hands out the underlying table. Cloudflare OS logs every resource an agent reads, and that record travels with the artifact.

Traditional approvals are synchronous: when an agent needs to do something that really changes the outside world, it creates a GitHub issue, sends a message, and stops — waiting for you to click confirm. You assign a task, go grab a coffee, and come back to find it stuck on step one. So people end up setting everything to auto-approve, or adding --dangerously-skip-permissions to skip the checks. Gatekeeper’s solution: don’t actually do the action — but pretend it’s done.

The first version was released to all employees in May 2026, and open-sourcing comes three months later. The scale numbers below are Cloudflare’s own estimates — they marked the hours saved as “estimates” themselves, and since this just came out today, no third party has verified anything yet.

• The README has an “early access” warning right at the top. This repo is a complete rewrite based on lessons from the first version. In their words: “pretty capable, but still rough around the edges — we know, we’re working on it.”
• If your company has custom internal systems without a ready-made Gatekeeper, someone will have to write them one by one. The repo includes an MCP (a standard interface for connecting AI to external services) bridge package, so existing MCP servers can be plugged in directly — but then you only get the level of control MCP provides.
• No external code contributions are accepted. The reasoning: AI has made writing code easy, the hard part now is reviewing and maintaining quality. They’ll only take small, easily verifiable fixes. And running everything on your own servers is still marked “coming soon” in the docs.