# Cloudflare OS: gadgets, Gatekeepers, and an operating system for AI work

> The open source agent workspace Cloudflare built for itself, released so other companies can copy it. What a gadget is, what a Gatekeeper does, and what the early access warning actually concedes.

**cloudflare/cloudflare-os** — Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems.

- Repository: https://github.com/cloudflare/cloudflare-os
- Website: https://os.cloudflare.app
- Stars: 11,333 · Forks: 1,352
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudflare-cloudflare-os

## An operating system in two senses, none of them the kernel kind

The README opens by pre-empting the obvious confusion. Cloudflare OS is not a traditional computer operating system, and the project uses the word in two other senses: an operating system for the company to be productive with AI in a way the security team can sign off on, and an operating system for AI workloads in the sense a traditional OS manages compute.

The provenance matters for reading the design. This was built inside Cloudflare first, where the README says a large portion of the workforce, from engineering to sales, uses it daily. The open source release exists so other companies can copy and customize it, and the project's own framing of the goal is that your company does not use Cloudflare OS, it runs Your Company OS. That is a statement about the intended adopter: an organisation willing to deploy its own instance rather than sign up for someone else's.

The repository description is more prosaic than the README: an agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company's context and systems. It is TypeScript, Apache-2.0 licensed, not archived, and the default branch is `main`. The last push recorded in the project metadata is 2026-09-21. The hosted instance lives at os.cloudflare.app.

## A gadget is a private copy of an app, sandboxed from every other user's

The central claim sits under the heading about a new way of thinking about software. Every user runs their own copy of the productivity apps they use. When you create a slide deck, you are not calling a SaaS product in someone else's cloud; the system creates a private instance of the slide deck software for you alone, in a sandbox separate from every other user's slide decks.

The README states two consequences of that arrangement. First, it claims the sandbox controls all access to your private instance, so it is not possible for the app itself to have a security bug that leaks your slides outward. Second, and this is the more interesting half, because the instance is isolated, you can freely modify its code. If the slide deck app is missing a feature, you ask your agent to add it, and the isolation is what makes that safe.

The README is upfront that this departs from the last 25 years of cloud architecture and software as a service, and gives the reason: when any user can prompt an agent to add the features they need, the centralised model stops making much sense. Whether the economics hold is the open question. A private instance per user per app is a lot of running software, and the repository gives no numbers on cost. The unit of isolation is the deployment boundary Cloudflare already knows how to operate, which is why the whole thing is Workers.

## Gatekeepers wrap each external service and defer approval instead of blocking on it

Gatekeepers are described as supercharged MCP servers. When you introduce an agent or gadget to an external resource, a Gatekeeper is created for that service and moderates the connection. Its listed jobs are specific: expose a clean Cap'n Web API that wraps whatever the service natively offers, handle authorization such as OAuth, enforce access narrowed to the resource the user actually intended, log every action the agent or gadget takes, and offer the human user a chance to approve or deny any action with side effects.

The claim about approval is where the project makes its strongest engineering argument. Traditional human in the loop setups approve synchronously: the agent stops and waits, the user walks away, comes back, finds nothing happened, and eventually flips on auto-approve or a dangerously skip permissions flag. Gatekeepers invert that. When an action needs approval, the Gatekeeper simulates the outcome locally, tells the agent the action completed, and returns simulated results if the agent reads them back. The agent proceeds and queues more work; the user approves in bulk or one at a time later.

That is a genuinely interesting trade, and it is also a trade. The agent is optimising against simulated state, so a chain of queued actions can be built on an outcome that never happens, or that happens differently. The README does not discuss that failure mode. Logistically each Gatekeeper is a separate Worker, and the project says it envisions those being deployed and maintained independently from OS instances, while admitting the details have yet to be worked out. A few Gatekeepers ship in the repository and deploy alongside your instance.

## The office suite comparison, taken literally

The user experience is compared to Google Docs or MS Office with one substitution: instead of a fixed set of file types, each file is potentially its own custom application, written by AI to serve your needs. Everything else follows from keeping the office metaphor: gadgets are private by default but shareable securely, and you can have thousands of them, created on a whim.

The example prompts show how that is meant to feel in practice. Asking for slides for an upcoming customer meeting uses a built-in slides blueprint. Asking for a collaborative whiteboard app builds from scratch, as does a tic tac toe game where you can then continue playing against the agent. Two prompts need an integration wired up first: an issue dashboard for a GitHub repo requires attaching the repo with the GitHub integration configured, and fixing typos in a Google Doc requires attaching the document with the Google integration configured.

The distinction worth noticing is between blueprints and from-scratch generation. The slides example leans on something already built, which is the sensible default. The issue dashboard example is the one that shows the Gatekeeper design under load, since it needs a real repository attached before any of it can run.

## Running the stack locally on wrangler and workerd

The quick start is two steps: install pnpm, then run a single command and open localhost:8787. The README is explicit that this runs the whole stack locally on wrangler and workerd, is not meant for production use, and is a quick way to see what the product does. An alternative is deploying to your own Cloudflare account through the deploy page linked from the README.

The command is indented in the README rather than fenced, which is a small sign of how much polish the project is carrying at this stage:

```bash
pnpm run-local
```

The `package.json` root package is private, version 1.0.0, type module, pinned to `pnpm@11.17.0`. Its scripts give a good map of what the repository actually does beyond serving a UI, and a couple are worth reading closely. `build` and `test` run through a task runner that filters out the root package itself and caches, so a `lint` script can chain a lint check, a scripts typecheck, and a full build typecheck and still finish in a sane amount of time. There are separate evaluation scripts, `evals` and `evals:ui`, which suggests the team is measuring agent behaviour rather than only shipping UI.

```json
"run-local": "node scripts/run-local.ts",
"dev-server": "node scripts/run-dev-server.ts",
"preview:deploy": "node scripts/preview/preview.ts deploy",
"preview:sweep": "node scripts/preview/preview.ts sweep"
```

The `preview:*` family is the most telling group. Deploy, delete, and sweep are three operations against short lived preview deployments, which is infrastructure you only need because a workspace spawns many throwaway environments.

## A monorepo built for agents to work in, and a warning worth reading twice

The tree is a pnpm workspace: a `packages/` directory, `pnpm-workspace.yaml`, a lockfile, and a root `tsconfig.json` alongside `vite.config.ts` and `wrangler.jsonc`. Two directories are unusual enough to notice. `.agents/` sits at the root, and `AGENTS.md` and `REVIEW.md` sit beside `CONTRIBUTING.md`. There is also a `plans/` directory, which reads like working notes kept in the repository rather than an issue tracker.

The development dependencies reinforce the picture. `@gadgets/scripts` is a workspace package, `@types/node` is pinned to 26.1.0, and typescript, vite, vite-plus, and wrangler all resolve through a catalog rather than fixed versions. That is a pnpm feature for centralising version ranges across a workspace, which fits a project where the same build tooling has to behave consistently across many packages.

The closing section of the README is the part to quote rather than paraphrase. Cloudflare OS is in a state of heavy development. This repository is version 2, a complete rewrite built on what the team learned from version 1. As of the August 2026 release, v2 is very capable but still has many rough edges, and the project asks you to consider it early access. There are no published GitHub releases behind that statement; the versioning story lives in the README paragraph. Taken together, the picture is a system that solves a real internal problem well, rewritten once already, and released before the edges were filed down.

## Conclusion

Cloudflare OS is a reference architecture rather than a product you can drop in. The parts worth stealing are the sandboxed per-user gadget, the per-service Gatekeeper Worker, and the simulated approval queue, and the parts to think hard about are the ones the README itself flags as unsettled, including how Gatekeepers get deployed and maintained outside an OS instance. Start with `pnpm run-local` on port 8787, build a tic tac toe gadget, then attach a real repository once you understand what the approval queue is actually deferring.

## FAQ

### What is Cloudflare OS?

Cloudflare OS is an open source agent workspace built on Cloudflare Workers, originally developed for use inside Cloudflare. It gives you an agent chat interface preloaded with company knowledge, sandboxed app building, and a security layer called Gatekeepers.

### What is a gadget in Cloudflare OS?

A gadget is a private instance of an app that belongs to one user and runs in its own sandbox, separate from everyone else's. The README argues this makes it impossible for the app to leak your content outward, and therefore safe for an agent to modify.

### How do I run Cloudflare OS locally?

Install pnpm, then run `pnpm run-local` and open http://localhost:8787. The README says this serves the whole stack on wrangler and workerd and is not intended for production use. You can also deploy to your own Cloudflare account instead.

## Sources

- [cloudflare/cloudflare-os on GitHub](https://github.com/cloudflare/cloudflare-os)
- [Issues](https://github.com/cloudflare/cloudflare-os/issues)
- [License: Apache-2.0](https://github.com/cloudflare/cloudflare-os/blob/main/LICENSE)
- [Project website](https://os.cloudflare.app)
- [README](https://github.com/cloudflare/cloudflare-os/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudflare-cloudflare-os