Cloudflare OS Explained: Inside the Open-Source AI Agent OS

Cloudflare just open-sourced the AI workspace it built for its own staff. Here's what's actually inside it.

Cloudflare OS is an open-source, browser-based AI agent workspace that Cloudflare released on August 5, 2026 under the Apache 2.0 license. It isn't an operating system in the Windows or Linux sense — there's no kernel booting on bare metal. It's a platform, built entirely on Cloudflare Workers, that gives every employee in a company their own sandboxed AI agent, a set of governed "Gatekeeper" connectors to internal systems, and the ability to turn a conversation into a small, shareable app (called a Gadget) without writing a line of code — or with plenty of code, if you want to edit it yourself.

I've spent the last few days pulling apart the GitHub repo, reading through Kenton Varda's Hacker News thread, and deploying a test instance to my own Cloudflare account. Most of the coverage so far repeats the press release almost word for word — "AI operating system," "agent workspace," three bullet points, done. What I haven't seen many places explain clearly is why the security model works the way it does, what you're actually agreeing to if you self-host it, and how it stacks up against the MCP-based agent tools most of us have already been using. That's what this guide is for.

I'm Mostafa Amaan, and on Valley4Techs I write practical, hands-on guides to the tools and infrastructure IT pros and developers actually use. Let's get into what Cloudflare OS is, how it's built, and whether it's worth deploying.

What Cloudflare OS Actually Is (Not What the Name Suggests)

The name is misleading on purpose, and even Cloudflare admits it in the project's own README. There's no scheduler managing CPU cycles, no filesystem driver, no device tree. What you get instead is something closer to a self-hostable Google Docs crossed with a code sandbox and a permissions broker — except every document, spreadsheet, or app starts as a conversation with an AI agent.

Cloudflare frames the "operating system" label in two specific senses, and once you see them separately, the product makes a lot more sense:

• An OS for the company, not the computer. It's meant to be the layer employees use to get work done with AI — safely enough that, in Cloudflare's own words, "the security team can sleep at night."
• An OS for AI workloads. Just like a traditional kernel manages processes and mediates their access to hardware, Cloudflare OS's backend (literally named workshop-backend in the repo) manages agents and mediates their access to company data and external services.

How the three core layers of Cloudflare OS connect — every agent request flows through the Gatekeeper layer before reaching any external system.

In practice, three pieces make up the platform:

1. Agent Workspace. A browser-based chat interface where an agent is grounded in the skills and context your organization has curated, and can write and run code in an isolated runtime.
2. Security & Governance Framework. The Gatekeeper system, which mediates every single request an agent or app makes to something outside its sandbox.
3. Gadgets. Personal, modifiable apps — what starts as "summarize this spreadsheet" can become a small internal tool that a whole team uses and keeps editing by just talking to the agent about it.

It was built by Kenton Varda, one of the engineers behind Cloudflare Workers itself, and he's been candid that it's a spiritual successor to Sandstorm.io, a personal-cloud sandboxing project he worked on a decade earlier. If you've followed Cloudflare's serverless platform, that lineage explains a lot of the design decisions here — particularly around isolation. And if you're curious about the broader trend of AI agents working together autonomously, our guide to building a team of AI agents covers the foundational concepts that platforms like Cloudflare OS are now productizing.

Gadgets: Apps That Get Built and Edited Through Conversation

This is the part of Cloudflare OS I think gets undersold in most of the coverage I've read. A Gadget is a small application — think an internal dashboard, a request-tracking tool, a data cleanup script with a UI — that an agent writes for you inside its own isolated sandbox. What makes it different from "AI writes you a script" is that the Gadget keeps existing after the agent finishes. You can open it later, ask the same agent to modify it, share it with a coworker, or hand off just the underlying code as what Cloudflare calls a Blueprint, which someone else can copy and adapt on their own.

Each Gadget runs in its own sandbox: server-side code executes in a Dynamic Worker with outbound networking disabled by default, and client-side code runs inside a sandboxed browser frame. Neither can reach the open internet, or your internal systems, unless you explicitly grant a capability through a Gatekeeper. That "starts with access to nothing" default is the single most important design decision in the whole platform — everything else is built around enforcing it.

A Gadget's lifecycle: the agent creates it from a conversation, it persists as a sandboxed app, and it can be shared as a live tool or exported as a reusable Blueprint.

Gatekeepers: How Cloudflare OS Actually Secures Agent Access

If you've built anything with the Model Context Protocol (MCP), Gatekeepers will feel familiar at first glance — and MCP servers are in fact supported as one kind of Gatekeeper. But the scope is intentionally wider. A Gatekeeper is a dedicated, service-specific Worker that sits between an agent and one external system: GitHub, an internal database, a company wiki, whatever you point it at. It owns the OAuth handshake, holds the credential, enforces the policy you've configured, and logs exactly what was read. If you're unfamiliar with how OAuth-based authentication flows work under the hood, our API fundamentals guide covers the core concepts that Gatekeepers build on top of.

The distinction that matters here is one MCP alone doesn't give you: MCP tells you which tools an agent is allowed to call. It doesn't tell you which rows, files, or repositories the agent actually touched while using that tool. A Gatekeeper does. Point one at GitHub, and you can scope an agent to a single repository, let it read issues but not source code, mask specific fields, apply rate limits, and require human approval before it can open a pull request — approvals that, per Varda, only block on side-effecting write actions, not reads within the agent's already-granted resources. If you're still learning the basics of Git and GitHub that underpin this kind of integration, our Git and GitHub beginners guide is a good place to start before configuring a GitHub Gatekeeper.

There's a second layer that I think is genuinely novel: observation tracking. Every resource an agent reads gets recorded, and that record travels with whatever the agent produces. If an agent builds a dashboard from a sensitive database table and a coworker later opens that dashboard, Cloudflare OS re-checks the coworker's permissions against the underlying data before showing them anything — not just against the dashboard itself. That closes a real gap: an agent joining data across two systems and handing the result to someone with fewer permissions than the data required, leaving no trace of what was actually touched.

What a Gatekeeper Configuration Actually Looks Like

Most coverage of Cloudflare OS describes Gatekeepers in the abstract — "they mediate access," "they enforce policy" — without showing you the actual configuration surface. That makes it hard to evaluate whether the security model is practical for your organization or just theoretically elegant. Here's what the real setup looks like, based on the repo's own example connectors and the configuration patterns I've seen while deploying a test instance.

A Gatekeeper is defined as a Worker with a structured configuration that specifies the target service, the authentication method, the scoping rules, and the approval policy. The configuration follows a declarative pattern — you describe what the agent is allowed to do, and everything not explicitly listed is denied by default. Here's a simplified example of a GitHub Gatekeeper that gives an agent read-only access to issues in a single repository:

// gatekeeper-config.ts — GitHub issues Gatekeeper (read-only)
export default {
  name: "github-issues-readonly",
  service: "github",
  auth: {
    type: "oauth",
    scopes: ["repo:read"],
  },
  policy: {
    allowedResources: [
      "repos/your-org/your-repo/issues",
      "repos/your-org/your-repo/issues/comments",
    ],
    blockedFields: ["author.email"],      // field masking
    rateLimit: { requests: 100, windowSeconds: 3600 },
    requireApproval: {
      onWrite: true,              // human-in-the-loop for writes
      onRead: false,              // reads flow without interruption
    },
  },
  observationTracking: true,          // log every resource the agent reads
};

The key properties worth understanding here are:

• allowedResources — This is the scoping mechanism. Instead of granting access to an entire GitHub organization, you specify exactly which API paths the agent can hit. Everything outside this list is blocked, silently — the agent never even knows the rest exists.
• blockedFields — Field-level masking. Even within allowed resources, you can redact specific data fields before they reach the agent. In this example, the author's email address is stripped from every issue response.
• rateLimit — Per-Gatekeeper throttling. This is separate from any rate limits on the AI model itself — it controls how many requests the agent can make to this specific service within a time window.
• requireApproval — The human-in-the-loop toggle. Setting onWrite: true means the agent can read issues freely, but any mutation — creating an issue, posting a comment, opening a pull request — gets queued for a human to approve before it executes.
• observationTracking — When enabled, every resource the agent reads through this Gatekeeper gets recorded as an "observation." That observation log follows whatever the agent produces, so downstream access checks can verify the original viewer's permissions.

For MCP-based Gatekeepers specifically, the configuration wraps your existing MCP server definition and adds the policy layer on top. If you're already running MCP servers in your stack, the migration path is straightforward — you keep the same tool definitions and add scoping, rate limits, and approval rules around them. Our MCP vs API comparison walks through the foundational differences if you're still deciding how MCP fits into your architecture.

Every agent request to an external service passes through five stages inside a Gatekeeper: authentication, resource scoping, field masking, rate limiting, and approval (for writes).

Can You Actually Self-Host Cloudflare OS?

Yes, and there are two genuinely different ways to do it — worth separating clearly, because a lot of "open source" launches quietly mean "open source, but it only really runs on our cloud."

• Deploy to your own Cloudflare account. The fastest path: run os.cloudflare.app/deploy and Cloudflare OS spins up on your infrastructure, using your Workers, your Durable Objects, and your AI Gateway for model routing. You'll also want Cloudflare Access configured for authentication.
• Run it entirely on your own servers. Because workerd, the Workers runtime itself, is open source, Cloudflare OS can technically run on infrastructure you fully control, with no dependency on Cloudflare's cloud at all.

From what I've seen testing it, the second path works, but the first-class experience — one-click deploy, managed AI Gateway, Access integration — is clearly built around Cloudflare's own cloud. That's not a criticism so much as the obvious commercial logic: give away the software, monetize the infrastructure it runs best on. If you're evaluating this for a company that's already deep in AWS or Azure, budget real engineering time for the fully self-hosted route, not the one-click deploy. For a broader look at how cloud database infrastructure compares across the major providers, our cloud database comparison across AWS, Azure, and Google Cloud covers the landscape you'd be working within.

On model choice, Cloudflare OS doesn't lock you to any single provider. Every inference call routes through AI Gateway, which is where the actual administrative control lives — which models are available to which teams, per-person or per-team spending budgets, rate limits, and routing rules that send routine tasks to cheaper, faster models while reserving frontier models for work that needs the reasoning power. If you've already experimented with building your own chatbot on Workers AI, this will feel like a natural extension of that same infrastructure — see our guide to building an AI chatbot on Cloudflare Workers AI if you haven't yet.

Prerequisites and Estimated Costs for Running Cloudflare OS

One thing I haven't seen any article lay out clearly is what you actually need — and what you'll pay — before Cloudflare OS does anything useful. The platform is open source and free to deploy, but "free to deploy" and "free to run" are different things once inference calls, Durable Objects, and AI Gateway usage start adding up. Here's the honest breakdown based on my own test deployment.

What You Need Before You Start

• A Cloudflare account on the Workers Paid plan ($5/month). The free Workers tier has hard limits on CPU time (10ms per invocation) and request counts that Cloudflare OS will exhaust almost immediately — especially once Durable Objects are involved, since those aren't available on the free plan at all. Budget at minimum the $5/month Workers Paid plan as a hard prerequisite.
• AI Gateway enabled. This is the model-routing layer that every inference call passes through. AI Gateway itself is currently free to configure, but the model calls it routes are billed based on the provider you choose — whether that's Cloudflare's own Workers AI models, OpenAI, Anthropic, or another supported provider.
• Cloudflare Access (for authentication). If you're deploying for a team, Access handles identity and login. Access is included in the Cloudflare Zero Trust free tier for up to 50 users. Beyond that, you're looking at the Zero Trust paid plans.
• At least one external API credential for any Gatekeeper you plan to configure — a GitHub personal access token, a database connection string, an OAuth app registration for your internal wiki, etc. Without at least one Gatekeeper connected, the agent is confined to its sandbox with no access to anything outside it.

Estimated Monthly Costs

The exact numbers depend heavily on team size and usage intensity, but here's a realistic range for a small team (5–15 users) based on what I've observed:

If you're planning to run the fully self-hosted route on workerd without any Cloudflare cloud dependency, the Workers/Durable Objects/Access costs disappear — but you'll need to provide your own compute, your own auth layer, and your own model-routing infrastructure. For teams already running virtualized homelab environments, our VMware vs Proxmox comparison can help you decide which hypervisor to run it on.

How Cloudflare OS Compares to What You're Probably Using Now

Most teams evaluating this aren't starting from zero — they're already running something. Here's how Cloudflare OS's approach differs from the two most common setups I run into.

Versus a plain MCP-based agent setup. If you've wired an agent up to a handful of MCP servers, you already have tool access. What you likely don't have is a permissions layer that tracks data provenance — which specific records an agent actually read — or an approval queue that only interrupts the agent for writes. Cloudflare OS's Gatekeepers add that governance layer on top of (and, for MCP servers, literally around) the same idea. If you're still deciding how MCP fits into your stack at all, our MCP vs API comparison is a good starting point before you evaluate Gatekeepers on top of it.

Versus a no-code automation tool. Platforms built around visual workflow builders are excellent at "when X happens, do Y," but they're not designed to hand an agent a sandbox and let it write arbitrary code for a one-off internal tool. Cloudflare OS explicitly supports both modes — deterministic workflows for known, repeatable sequences, and open-ended agent sessions for the messier, judgment-heavy work. If you're currently running scheduled automations, our n8n automation guide covers the workflow-first approach that Cloudflare OS's workflows feature is conceptually closest to.

Feature-by-Feature Comparison Matrix

To make the evaluation easier, here's a side-by-side comparison of Cloudflare OS against the most common alternatives I see teams considering. This covers the dimensions that actually matter when choosing an AI agent platform for a team — not just feature checkboxes, but the practical realities of each approach.

If your interest in Cloudflare OS comes from wanting AI agents to actually retrieve accurate information from your own documents rather than hallucinate answers, it's worth understanding the retrieval layer underneath any of these tools first — our RAG explained guide walks through exactly how that grounding works. And for understanding the difference between the AI paradigms powering these tools, our machine learning vs deep learning vs generative AI comparison provides the conceptual foundation.

Who Should Actually Deploy This Right Now

Based on what's in the repo today, I'd split it this way:

• Worth trying now: teams already running production workloads on Cloudflare Workers, and IT/security teams who want a governed way to let non-technical staff build small internal tools without opening a ticket for every one of them.
• Worth testing in a lab, not production: anyone evaluating it as a general-purpose agent platform. Cloudflare itself calls this early access — the first post-launch commit in the repo was a logout fix, and the maintainers have said a v2 rewrite is planned. Rough edges are expected and acknowledged.
• Probably not the right fit yet: organizations with no Cloudflare footprint and no appetite for managing OAuth-based Gatekeepers per integration. The self-hosted-elsewhere path exists, but it's not the polished experience.

If you're the kind of admin who likes testing new self-hosted platforms in a sandbox before anything touches production, treat Cloudflare OS the same way you'd treat any new self-hosted stack — our best self-hosted apps for a Proxmox homelab roundup is a good place to spin up an isolated environment first.

5 Mistakes to Avoid When Evaluating Cloudflare OS

1. Assuming "open source" means "runs anywhere equally well." It runs on open-source workerd, technically, but the deployment tooling, AI Gateway integration, and Access-based auth are all built for Cloudflare's cloud first. Plan accordingly.
2. Deploying a Gatekeeper with broader access than the task needs. The whole security model depends on scoping — a single repository instead of a whole GitHub org, read-only instead of read/write. Treat every new Gatekeeper the same way you'd treat a new OAuth app requesting permissions.
3. Treating this as production-ready day one. It's early access by Cloudflare's own admission. Run it in a lab or a low-stakes internal use case before trusting it with anything customer-facing.
4. Ignoring the model-spend controls. Because AI Gateway lets any team spin up agents, set budgets and rate limits per person or team from day one — not after the first surprising bill.
5. Confusing Gadgets with generated scripts. A Gadget is a persistent, shareable, permissioned object. Don't skip setting up sharing and access rules just because it started as a quick one-off request.

Frequently Asked Questions