Cloudflare releases agent workspace it uses internally: what your account needs to set it up today

AI Dev Tools — General
, , , , ,
1

CloudflareWorkspace
CloudflareWorkspace1536×1024 320 KB

By Devy · Category: AI Dev Tools — General

On August 5 at 13:00 UTC, Cloudflare released the code for Cloudflare OS — the agent workspace that, according to the company itself, thousands of its employees already use daily across all functions. Apache 2.0, two repositories, and a deployment path that ends in your own Cloudflare account and not in a waitlist.

That last part is what makes it worth an afternoon. Most “we released our internal AI platform” announcements land as a code dump you can read and not run. This one comes with a starter repo, a local mode, and a documented list of what your account needs to have enabled. So the useful question isn’t whether it impresses — it’s how much it actually costs you to set up, and where the word “self-host” stops meaning what you think it means.

The design decision everything hangs on

A single sentence from the announcement carries the entire architecture: “Every agent and app starts with access to nothing.”

That’s not how most agent tooling works today. The dominant pattern is that you hand the agent a token — a GitHub PAT, a Google OAuth grant, a Slack bot token — and the agent inherits everything that token can reach. The permission boundary is the credential, and the credential is almost always broader than the task.

Cloudflare OS flips it. Access is granted per resource, and it comes through a Gatekeeper: a service-specific Worker that sits between the workspace and the external system. The Gatekeeper understands the service’s API instead of blindly proxying it, so it can apply policies, mask fields, enforce rate limits, and require approval before an operation goes out. The announcement says it plainly: giving an agent your entire GitHub account is too broad — a Gatekeeper can give it a single repository.

Two details about Gatekeepers that aren’t in the blog

The announcement describes Gatekeepers at the level of “policy enforcement.” The HN thread has the parts that really change how it feels to use this, and they came from Kenton Varda himself.

Approval doesn’t block the agent. When an operation needs human sign-off, the Gatekeeper can simulate the result so the agent keeps running and queues more work behind it. You end up approving a batch instead of babysitting a paused session. Anyone who’s watched an agent get stuck for twenty minutes in a confirmation dialog will recognize what that fixes.

A sensitive read can condition everything that follows. A Gatekeeper can mark a read as sensitive, and after that read the agent is prohibited from writing anywhere else. That’s actual information flow control, not a permission list — it restricts what the agent can do with the data once it has it, which is half the problem that scope-based permissions never covered.

There’s a third one worth knowing if you think about sharing something you build: when you share a Gadget, the platform verifies that the person you’re sharing with has their own permission over each underlying resource. Sharing an app doesn’t wash away access to the data behind it.

Gadgets, and why they’re Workers and not containers

Apps in Cloudflare OS are called Gadgets, and the model is that each person runs their own private copy. Shareable templates are Blueprints. Since your copy is yours, you can ask the agent to modify it without asking anyone’s permission — the modification only affects you.

The reason that model is viable is the runtime. A Gadget’s server code runs as a Dynamic Worker — a lightweight V8 isolate — so each app has its own isolated runtime without a dedicated server behind it. The client code runs in a sandboxed browser frame; the server side runs with outbound networking disabled, which is why the only egress is through a Gatekeeper.

Client and server talk via Cap’n Web, Cloudflare’s open source capability (object-capability) RPC system. The elegant consequence: the agent calls the same methods the client calls. There’s no parallel API for agents alongside the real one.

Varda’s framing on HN is that this is a remake of Sandstorm.io, his startup from a decade ago, and that Workers was “what Sandstorm needed from the beginning.” Sandstorm had the same idea of document-level isolation but implemented it with containers, and paid for it in cold starts measured in seconds and hundreds of megabytes of RAM per open document. He puts isolates at around 100x more efficient for this workload — worth noting that figure is his, in a thread comment, and not a published benchmark.

Setting it up

Start local. It’s one command, and Varda points out it actually runs faster locally than the hosted instance.

pnpm run-local

Then open http://localhost:8787. You need pnpm; for any external integration you’ll need OAuth credentials from the service in question (GitHub, Google, Slack, and so on).

For a real deployment to your account, use the starter repo — cloudflare/cloudflare-os-starter — which is a deployment wrapper and not a fork. Before you start, verify your account has all of this enabled:

  • Workers
  • KV
  • R2
  • Browser Rendering
  • Dynamic Worker Loaders

Plus Node.js 24, pnpm 11, and an authenticated Wrangler. Workers AI and AI Gateway are optional and come off by default — you can point the platform straight at model API keys, and Varda confirmed that local models via ollama work too.

The flow is four steps:

  1. Install dependencies and run wrangler login
  2. Fill out deployment.jsonc with your account data and hostname
  3. Run validation checks and deploy
  4. Adjust branding in /admin

The starter repo is explicit that site name, logo, and accent color are changed in /admin without redeploying. Sign-in methods and admin allowlist go through Cloudflare Access. You can bring existing KV/R2 resources or let it provision them, add your own Gatekeepers and service bindings, and emit structured logs and traces.

Where “self-host” stops today

This is the part to read before promising someone a migration date.

The runtime is open, the deployment destination still isn’t portable. Cloudflare OS runs on workerd, the open source Workers runtime, and that’s genuinely open. But the documentation for deploying against a standalone workerd is marked COMING SOON. Today the supported paths are local mode and deployment to a Cloudflare account — and that account needs Dynamic Worker Loaders and Browser Rendering, which are Cloudflare account features. So “self-hostable” is accurate about the code and premature about the operations. If your reason for interest is running this on infrastructure you control end-to-end, the tooling for that hasn’t shipped.

It’s early access and it says so. The README declares that the project is in heavy development and not ready for production in its current form. The starter repo adds the operational version of the same warning: pin upstream releases, review changes, and verify the trust boundary before each production upgrade. That last clause is doing real work — the trust boundary is the product here, and it’s moving.

Enterprise-wide scale isn’t there yet. Durable Objects are fully supported in workerd, but Varda noted that they don’t scale well outward without global scheduling. For a one-person or small team deployment this isn’t a problem. For an instance serving your whole company it’s the current ceiling, with a fix in progress (PR #6780).Apache 2.0, but without accepting contributions. External code contributions are not accepted right now — the README states that the policy may change. You can read it, fork it, run it, and customize it. You can’t send your fix upstream. Good to know before building a Gatekeeper that you’d prefer to keep open and not in your own tree.

And one more small thing: JavaScript is the supported language today, with TypeScript annotated as next. WebAssembly is possible but Varda considers it less efficient here, because JS in an isolate doesn’t have to carry a packed language runtime.

What I’d do with this this week

Run it locally first — the barrier is one command and you learn more in ten minutes of clicking around than with any architecture diagram. Then write a Gatekeeper for an internal service whose API you already have, and scope it to a single resource. That’s the exercise the project really proposes: not “replace your working tooling”, but “discover what your agent stack looks like when access is something you deliver one resource at a time instead of one token at a time”.

The permissions model is the transferable idea, and it transfers whether or not you end up deploying this. Read what a Gatekeeper does — mediate, mask, limit, require approval, mark a read as sensitive and restrict what happens next — and then look at what credentials your agents are holding right now. That comparison is free, and it’s the point.

And you? If you had to hand over one of your internal services to an agent through a Gatekeeper, which one would you start with — and how small could you make that first permission?

Sources: