On 5 August 2026 Cloudflare open-sourced Cloudflare OS, the AI workspace a large part of its own workforce uses daily. It is not a chatbot with connectors. It gives every user a private instance of the apps they work in, lets an agent build new ones on request, and puts a mediation layer called a Gatekeeper between those agents and every external system they touch.
We had it running locally the same week, then wrote a Gatekeeper for the CRM we run our own business on. This is what we found — including the parts that will change how you plan around it.
The licence is the story
Cloudflare OS ships under a plain Apache-2.0 licence with no additional rider — no Commons Clause, no source-available restriction, no field-of-use limit. We checked the LICENSE file in both repositories rather than trusting the announcement.
In practice that means you may fork it, rebrand it, run it for your own company, and pay someone to do that for you. Cloudflare’s own framing is that the point is not to use Cloudflare OS but to make it Your Company OS. The single limit is the ordinary trademark clause: describe where the code came from, do not name your product after theirs, and do not imply endorsement.
That is a genuinely unusual amount of freedom for a platform of this size, and it is the reason the project is worth a serious look rather than a bookmark.
What is still moving
Three things temper the enthusiasm, and all three are stated by Cloudflare rather than inferred by us.
Two of the core primitives are in open beta. Dynamic Workers went to open beta in March 2026 and Durable Object Facets in April. Neither has an announced general-availability date. The app-building layer — the part that gives each user their own sandboxed instance with its own database — rests on both. If your change-control process treats beta dependencies as a blocker, that conversation happens before the pilot, not after.
The repository describes itself as early access. The README is direct about it: version 2 is “very capable, but still has many rough edges.” We agree, and we mean that as a compliment to the honesty rather than a criticism of the code.
A fully managed version is coming, with no date attached. Cloudflare says it is bringing Cloudflare OS to the dashboard as a managed product. Anyone planning to sell deployment labour around the self-hosted version should price that work knowing it has an expiry date nobody has published. What the managed product cannot commoditise is the part specific to you: your institutional context, your policies, and connectors for the systems only you run.
Upstream contribution is closed — plan accordingly
This is the finding that changed our own plan, and it is easy to miss because it sits at the bottom of the README.
Cloudflare is not seeking outside code contribution. Small, trivially verified fixes are welcome; anything beyond “a dozen or so lines” will be closed with a pointer to that guideline. Their reasoning is sound — AI made writing code cheap, review did not, and a large donated PR hands them the easy half of the job.
The consequence is concrete. If you write a Gatekeeper for a system Cloudflare does not cover, it is your repository, not a pull request. Our own connector is roughly 1,800 lines; submitting it upstream would waste everyone’s time. For larger ideas the open channel is a GitHub discussion, not a PR.
We think this makes third-party connectors more valuable rather than less. The managed product will still need connectors for regional and self-hosted systems that Cloudflare has no reason to write, and those will live in other people’s repositories by design.
Gatekeepers are the interesting idea
The security model deserves more attention than the workspace UI.
An agent starts with no access. Every external system it reaches goes through a Gatekeeper — a Worker specific to that service that wraps the service’s API, handles authorisation, narrows access to the exact resource the user intended, logs every read, and holds every write for human approval.
The part we had not seen done well elsewhere is what happens while a write is waiting. Conventional human-in-the-loop makes the agent stop and wait, which is why so many people end up approving everything just to get their work done. A Gatekeeper instead simulates the pending change: the agent is told the write succeeded, later reads reflect a world in which it landed, and the agent keeps working. The human approves or rejects a batch later, at their convenience. When the simulation is faithful, the agent never needs to know approvals exist.
Building one made the discipline concrete. Writing a connector for our own CRM meant deciding, method by method, which calls were observations to be logged and which were actions to be queued, and then deciding who is allowed to see data the agent already read once an app is shared with a colleague. That last question — the observer model — is the part most integrations skip, and the framework will not let you skip it: the code does not type-check until you answer it.
That connector is published, and we wrote up the work behind it: building a Gatekeeper for Twenty CRM. It sits alongside the other connectors we have built.
Eight things the README does not tell you
We kept a log while setting it up. The short version:
pnpm run-localdoes everything — installs, builds, and serves the whole stack onlocalhost:8787. It hashes your sources and skips straight to serving when nothing changed.- It ran fine on Node 22 despite a newer version being suggested elsewhere in the project.
- Self-hosted deployments have unlimited AI usage by default and built-in accounts. The daily-allowance and credit-billing flow is opt-in and exists for running it as a public multi-user service.
- Sign-in can be handled by Cloudflare Access, which matters if you already gate internal tools that way.
- The development server auto-discovers connector packages by directory name at startup — which supersedes a manual wiring step still described in the project’s own authoring guide.
- Because discovery happens at startup, a newly added connector needs a restart, not a hot reload.
- One file in a connector must be a symlink rather than a copy, and the build fails in a way that does not obviously say so.
- Deploying to Cloudflare needs a paid Workers plan — Dynamic Workers is not on the free tier — so there is no free-tier client demo beyond running it locally.
None of these is a defect. They are the ordinary friction of a young platform, and they cost us hours we can save you.
What we would tell a company considering it
Run it locally first — it costs nothing and takes about twenty minutes. Treat the beta primitives as a real question for your change-control process rather than a footnote. Assume deployment labour is a depreciating asset and put your effort into the context, the policies, and the connectors that are specific to you. And if a system you depend on has no Gatekeeper, budget for writing one, because it will not arrive upstream.
The workspace itself is the commodity here. What decides whether any of this works in your company is whether the knowledge it reasons over is organised, current, and owned by you — which is a different problem, and the one we spend most of our time on.
Get the setup runbook
The detailed version of the log above — the full connector authoring walkthrough, the CRM API shapes that cost us the most time, the observer-verification decision table, and the deployment checklist with the paid-plan gates marked — is in the companion runbook.