Ten years ago, Kenton Varda shut down a startup. The idea wasn't bad — the problem was that almost nobody had the time or skill to actually customize the software they used.
This week, he brought back the exact same idea inside Cloudflare. This time, thousands of employees use it every day.
Why did it fail 10 years ago?
Varda is the engineer who designed Cloudflare Workers. But before that, he ran a startup called Sandstorm.io — a self-hosted platform that spun up a separate instance for every document or app you touched.
The idea still holds up. It just didn't sell. Varda's own explanation, given recently, is simple — almost nobody in the world had the ability to add a feature to the software they were using.
The question he's asking now is this: "What if, when you wanted a new feature in the software you are using, you could just prompt your agent to add it?" He's betting that AI agents removed the exact barrier that killed Sandstorm. That's how Cloudflare OS was born inside the company, rolling out to every employee this past May.
So what's actually different this time?
Cloudflare OS has three parts: an agent workspace loaded with company context, a security and governance framework, and a personal app layer. The second one is the real story.
Most existing setups (MCP included) hand agents an API key or OAuth token directly. Cloudflare OS agents start with zero access to anything. A "Gatekeeper" worker sits in front of every service, holds the OAuth session and API credentials itself, and never lets the agent see them.
| Typical setup (shared API keys) | Cloudflare OS (Gatekeeper) | |
|---|---|---|
| Who holds credentials | The agent itself | The Gatekeeper worker only |
| Starting access | Often broad by default | Zero access to start |
| Access logging | Logs that a request was sent | Logs the actual rows, files, repos read |
| Write actions | Often auto-executed | Requires human approval |
Here's why it matters: even if data from several systems gets combined and handed to someone with lower clearance, the original access trail stays intact. As the authors put it, "authorization has to compute where data is allowed to travel."
The personal app layer runs on the same philosophy. Build a slide deck, and it doesn't live on some shared SaaS server — you get your own private app instance, called a "Gadget." Each one owns its own SQLite database, and data can't leak across Gadgets by design. Want to share just the code, not the data? You hand out a "blueprint" instead.
So is it actually worth trusting yet?
The launch post hit 658 points and 330 comments on Hacker News on day one — enough to sit near the top of the board that day. Varda himself showed up in the thread to confirm the terms directly: "We are making this whole thing open source, Apache 2.0 license, no catch," and "It's 100% open source and self-hostable!"
Not everyone was sold, though. The name took the first hit. "It's awful naming if they have to explain it" (orphea), and "They even put it in quotes, because they know what they did" (arandomhuman).
Lock-in worries came up too. "This is far too Cloudflare flavored to be interesting to me... I don't feel safe building on this" (echelon), "smells like lock-in to me" (EasyMark). Someone also ran the math on usage-based billing scaling up as headcount grows.
Worth weighing against the alternatives, too. Glean, a common enterprise search-and-assistant tool, doesn't publish pricing and is reportedly built around roughly 100-seat minimum contracts. Dust charges around $29 per user with no seat minimum. Both are SaaS, meaning your data sits on their cloud. Cloudflare OS itself is free (Apache 2.0), and it runs directly on your own Cloudflare account — you only pay for the infrastructure you use.
Heads up
As of August 2026, this is still early access. The repo's own README says it's "functional enough, but there are still rough edges," and self-hosting on workerd is still being documented.
How to actually try it
- Skim the repo first
Start with github.com/cloudflare/cloudflare-os — read the README and how Gatekeepers and Gadgets fit together. - Spin it up locally
Runpnpm run-localand open localhost:8787 — no deployment needed to try it. - Deploy it for real
Go to os.cloudflare.app/deploy — all you need is a Cloudflare account and a few minutes. - Wire up one Gatekeeper
Start with a read-only connector (e.g. a GitHub repo) and check the logs to see exactly what the agent actually read. - Build and share one Gadget
Make a doc or a deck, then hand a teammate a data-free blueprint instead of the real thing.
Want to go deeper?
Cloudflare's official announcement The three components and the roadmap, straight from the source. blog.cloudflare.com
The cloudflare/cloudflare-os repo The actual code, the local run command, the deploy scripts. github.com
A deep dive on the Gatekeeper security model The most detailed breakdown of access logging and field masking. helpnetsecurity.com
Kenton Varda's Hacker News thread The original discussion, with the creator answering questions directly. news.ycombinator.com
A plain-language explainer on Gatekeepers and Gadgets Covers the Sandstorm connection and how blueprint sharing works. explainx.ai
Glean vs. Dust pricing and architecture comparison Useful if you're weighing this against a paid SaaS option. usecarly.com
