Cloudflare OS: An Open-Source Platform for Agents, Apps, and Work

Cloudflare just open-sourced the AI workspace it built for its own employees

Cloudflare gave every one of its own employees a first version of this tool in May 2026. By August, "thousands" of them — not just engineers — were using it daily to write docs, build slide decks, automate busywork, and knock together small internal apps. On August 5, 2026, as part of its "Agents Week" event, Cloudflare rebuilt that tool and open-sourced it as Cloudflare OS, a platform any organization can self-host on cloudflare/cloudflare-os.

That's the press-release version. What actually makes Cloudflare OS worth a second look is the architecture underneath it — and the fact that the person who designed it, Kenton Varda, spent Hacker News comment after comment explaining that he already built this once, a decade ago, and it failed for a reason AI may have just removed.

Two days before this launch, Cloudflare previewed the underlying agent runtime on its own — see our coverage of Cloudflare Computer. Cloudflare OS is what gets built on top of that runtime.

TL;DR

What are the three parts of Cloudflare OS?

Cloudflare OS is built from three pieces that work together rather than three separate products:

1. An agent workspace — a browser-based interface, no coding required, preloaded with a shared library of company context and "skills." When one employee documents a better way to do something, that procedure becomes an instruction every other agent in the org can follow. Agents can research using internal data (writing code to search and filter instead of pulling whole datasets into context), produce docs and slides tied to live data that still export to normal formats, build small collaborative apps, or run mostly-deterministic scheduled workflows.
2. Gatekeepers — a governance layer that mediates every agent's access to internal and external systems. This is the part worth understanding in detail, below.
3. Gadgets — the app platform. Every app an agent or human builds runs as its own sandboxed, full-stack instance rather than shared multi-tenant code.

Every inference call routes through Cloudflare AI Gateway, so an organization can mix models per task and attribute spend per person, team, or workspace — Cloudflare OS is explicitly model-agnostic, not tied to any one provider.

How does Cloudflare OS actually control what an agent can touch?

This is the part the official blog post spends the most words on, and for good reason — it's the actual technical differentiator, not the chat UI.

Cloudflare Access gates who can enter Cloudflare OS at all. Once inside, every agent and every app starts with access to nothing. To use a resource — a GitHub repo, a data-warehouse table, a Slack channel — the agent has to request access to that specific resource, and a human has to grant or deny it. Once approved, that access becomes a typed binding baked into generated code, something like env.PROJECT.listIssues(...). The underlying credential itself never touches the agent or any code it writes.

Server-side agent and Gadget code runs inside a Dynamic Worker, a new Cloudflare Workers primitive built for this project, with all outbound networking disabled by default. Client-side code runs in a sandboxed browser frame. Neither can reach the open internet except through capabilities the platform explicitly hands them.

External services are handled by a Gatekeeper — a dedicated Worker sitting between Cloudflare OS and one specific service (GitHub, Home Assistant, whatever the org connects). It understands that service's API well enough to scope access far more narrowly than "hand the agent your whole account": read-only on one repository, no source access, field masking, rate limits, human approval required before anything writes. The Gatekeeper holds the OAuth credential, logs every read, and mediates every action with a real-world side effect. The agent only ever sees a small, typed TypeScript surface — not the underlying API.

What is "taint tracking" and why does it matter for sharing?

Cloudflare OS logs every resource an agent has observed, and that observation history stays attached to the agent and to anything it produces. If a second person later opens that workspace, talks to the agent, or views its output, Gatekeepers re-check that second person's own access to every resource the agent touched along the way.

The practical case this closes: someone builds a dashboard off a sensitive data-warehouse table, shares the dashboard with a colleague — and that sharing act cannot become a backdoor path for someone who couldn't query the table directly to see its data anyway. The same observation log also gates whether a "tainted" agent can make further external writes, invite collaborators, hand off to another agent, or make outbound calls. Cloudflare frames this explicitly as a defense against prompt injection and secret exfiltration — a threat model our MCP security guide covers in more general terms, and one that recent incidents like GitLost and The Memory Heist show is not hypothetical.

What is a Gadget, and why does Kenton Varda keep calling this "Sandstorm with AI"?

This is where the Hacker News thread (151 points, 72 comments at time of writing) got genuinely more informative than the official announcement — by Varda's own admission. Replying directly in the comments, he said: "we had so many things we wanted to say... the blog post is for an enterprise audience, my tweet thread is for the hacker audience."

Varda's framing: Cloudflare OS is a rebuild of his own 2015-era startup, Sandstorm.io, on top of Cloudflare Workers, "with AI." A Gadget — Cloudflare OS's term for one instance of an app — is the same idea as a Sandstorm Grain: a fine-grained, per-instance sandbox. Every document gets its own separate sandboxed instance of the document-editor app, not a slot in one shared multi-tenant server.

Technically, each Gadget has client code (browser UI) and server code (state and behavior), loaded on demand as a Dynamic Worker and instantiated as a Durable Object Facet — both new Workers-runtime primitives Cloudflare built specifically for this project. That combination gives each app instance its own isolated SQLite database and a lightweight V8-isolate runtime, without a dedicated server or container per app. Client and server talk over Cap'n Web, Cloudflare's open-source object-capability RPC system — and, notably, an agent can call the exact same server methods a human-built Gadget exposes, so any tool a person builds for themselves is automatically usable by an agent too.

Varda claims two structural benefits fall out of this per-instance model:

1. Containment by construction. The platform controls access by controlling who can reach a given Gadget at all. A bug in one Gadget instance can't leak it to someone else — even someone with access to other instances of the same app.
2. Everyone can fork their own copy. Because every user runs their own literal instance of an app's code, they can freely modify it. "If you want a new feature, just ask your agent to add it" — something Varda argues doesn't work in ordinary multi-tenant SaaS, because you're not running your own copy there.

His retrospective on why this failed the first time is blunt: Sandstorm tried this exact idea ten years ago, and "the world wasn't ready" because too few people had the skill or patience to modify their own software. His bet is that AI agents remove that bottleneck now.

Sharing in Cloudflare OS reflects the same two-mode idea Varda describes: you can share a Gadget itself (real-time collaboration on shared state), or share a blueprint — a copy with the same code but none of the original's data, history, credentials, or connected resources. That second mode is meant to enable "modify it yourself instead of filing a feature request" inside a team, an idea related to the software-for-one trend of building single-user apps with coding agents, just aimed at teams instead of individuals.

Is Cloudflare OS actually open source and self-hostable?

Genuinely, more than most launches that use the phrase. The repository is Apache-2.0 and it's built on Cloudflare's open-source workerd runtime, not a closed hosted-only wrapper. Cloudflare shipped two repos: the core platform, plus a separate example-deployment repo — Cloudflare's own internal configuration — that consumes the core without patching it, meant as the template for how any org wires in its own UI, integrations, and skills.

Varda confirmed on Hacker News that you genuinely "can run it at home if you want," and that it works with local LLMs through Ollama support — he says it's "honestly... faster running locally" than the hosted version for some workloads. He does flag a real limit on how far the trust model extends: it still assumes you trust whatever LLM provider you route through not to exfiltrate what it sees in your prompts. Most providers offer zero-data-retention options, and local models via Ollama are the option for anyone unwilling to extend that trust at all.

The skepticism worth taking seriously, from HN commenters including hobofan, zsoltkacsandi, and tekacs: the whole system leans on Cloudflare-proprietary runtime primitives — Dynamic Workers, Durable Object Facets, Cap'n Web — that currently only run well on Cloudflare's own platform. "Open source" as a license is real; "open source" as practical vendor-independence is not there yet, and it's a criticism Cloudflare has faced on prior open-source launches too.

A concrete cost detail reported on the thread and worth verifying before you plan a deployment: the free Cloudflare Workers plan reportedly cannot run Dynamic Workers, meaning Cloudflare OS as shipped needs a paid Workers plan. Cloudflare's own repo doesn't spell this out prominently, so treat it as HN-reported rather than officially confirmed pricing.

Is Cloudflare OS's sandbox actually secure — or just differently shaped than a container?

This is the sharpest unresolved thread in the comments, and Varda didn't fully close it.

Varda's core security claim is strong: "the sandbox is so secure that you can pretty much go wild — the AI cannot introduce a significant security bug." Commenter layer8 pushed back on the premise directly — a claim like that can only hold if the app truly can't affect anything outside its sandbox, which by definition limits how useful the apps can be. That's a real tension, not a resolved one: more isolation is safer and also more restrictive, and nothing in the thread shows exactly where Cloudflare OS lands on that trade-off in practice.

Commenter tinco asked the more concrete architecture question: what does a per-instance sandboxed Gadget actually buy you over a standard Docker or Linux container — especially given that OpenAI itself had to move from containers to microVMs after agents found container-escape paths during testing? Is an isolate-based Workers sandbox more robust than a container, or just different? Varda didn't directly answer this in the thread. It's an open technical question, and it's the same question our Cloudflare Computer coverage raises about isolates-vs-containers at scale — Cloudflare's bet is that isolates hibernate and start fast enough to serve as the default, with containers attached on demand for heavier work.

On approvals specifically, Varda added detail the blog post skipped: Gatekeepers only require human approval for side-effecting (write) actions — reads within an agent's granted resources don't block. For writes that do need sign-off, a Gatekeeper can simulate the outcome so the agent keeps working and queues more actions instead of stalling, letting a human batch-approve at the end rather than reaching for a blanket "auto-approve" — a pointed contrast with the "yolo mode" pattern common in other agent tools, including the auto-approve modes covered in our Claude Code permission modes coverage. Varda also confirmed the taint-tracking system that flags risky actions is "still evolving," not a finished feature.

Should IT be worried about "Gadget sprawl"?

Commenter badlibrarian raised the most realistic enterprise-adoption risk in the thread, and it isn't a security bug: it's the SharePoint-sprawl failure mode. If every employee can fork and modify their own copy of an internal tool, an org can end up with dozens of divergent, unmaintained forks and no clear canonical version — a governance problem, not a sandbox-escape problem. Nothing in Cloudflare OS's architecture directly prevents this; the blueprint-sharing model that makes forking easy is the same feature that makes sprawl easy. It's a genuine trade-off for IT teams to plan around, distinct from anything Gatekeepers protect against.

A related, softer criticism came from fny and philistine: the official blog post itself reads as vague relative to Varda's own tweet thread and the GitHub README — both of which HN commenters found far clearer about what's actually being shipped. That's a real gap between how Cloudflare marketed this and what a technical reader needed to know first, and it's part of why quoting Varda directly, rather than only the press release, matters for understanding what Cloudflare OS is.

Is "Cloudflare OS" a real operating system?

No, and Cloudflare's own repository says so. Several commenters (thehamkercat, fnoef, and others) pushed back on the "OS" branding as buzzword inflation, since it isn't a bootable, traditional operating system. The cloudflare/cloudflare-os README clarifies the metaphor directly: it's "an operating system for the company to be productive with AI," and "an operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads" — a looser, kernel-and-drivers analogy (Gatekeepers standing in for drivers) rather than a literal claim.

That naming debate is a recurring one this year — see our coverage of Fable-OS, which actually is a from-scratch x86_64 kernel controlled by an agent, and Perplexity's "multiplayer agentic operating system for work", which uses the same loose framing Cloudflare does. Cloudflare OS sits closer to Perplexity's usage than Fable-OS's — it's a workspace and sandbox layer, not a kernel.

How does Cloudflare OS compare to other agent-workspace launches this month?

Cloudflare OS's distinguishing bet, per Varda, isn't the chat interface — every one of these has that. It's the per-instance sandbox plus zero-default-access Gatekeepers, applied to internal enterprise systems specifically, which is a narrower and more security-sensitive target than most "AI office suite" launches this quarter.

What should you actually try first?

If you're evaluating this for a team rather than reading about it out of curiosity, a reasonable first pass:

git clone https://github.com/cloudflare/cloudflare-os
cd cloudflare-os
pnpm install
pnpm run-local        # runs locally per the README, no Cloudflare account required to start

From there, connect one low-stakes internal resource through a Gatekeeper — a read-only GitHub repo is the safest first test — before wiring in anything with write access or sensitive data. Given the reported Workers Paid plan requirement for Dynamic Workers, confirm current Cloudflare Workers pricing before committing to a production deployment rather than a local trial.

Related on explainx.ai

• Cloudflare Computer: Agents Need Isolates, Not Just Containers — the runtime Cloudflare OS is built on, same Agents Week
• From ReAct to production harness — DAG, Planner/Worker/Critic, budget pressure — orchestration primitives that sit inside a Gatekeeper-gated workspace
• Cloudflare Wallets: programmable payments for AI agents — the payments layer released the same week
• MCP Security Guide 2026 — the broader threat model Gatekeepers are one implementation of
• Fable-OS: a real kernel, not yet bare metal — what an actual agent-controlled OS looks like, for contrast
• Perplexity Computer Projects: a multiplayer agentic OS — a competing "agentic OS" framing to compare against
• Genspark GenOffice: open-source AI office — another open-source productivity release the same week
• Is Claude Cowork safe? — permission-mode and auto-approve trade-offs in a different agent product
• Software for One: personal apps with AI coding agents — the individual-scale version of the "modify your own copy" idea

Sources

• Cloudflare Blog — Cloudflare OS: an open platform for agents, apps, and work (Aug 5, 2026)
• Cloudflare Blog — How we're rethinking work at Cloudflare with Cloudflare OS
• GitHub — cloudflare/cloudflare-os
• Cloudflare Changelog — Preview: @cloudflare/computer agent runtime
• Sandstorm.io — About

Version details, star counts, and pricing terms above reflect Cloudflare OS as of its August 5, 2026 launch; check the GitHub repository and Cloudflare Workers pricing pages for current figures before deploying.