Thread

Cloudflare OS: an open platform for agents, apps, and work

641 points · 315 comments · speckx

rozenmd · 1785939425 · focus · HN ↗
I liked Kenton's take on this: <a href="https://x.com/KentonVarda/status/2084990137180590572?s=20" rel="nofollow">https://x.com/KentonVarda/status/2084990137180590572?s=20
Text from tweet:
Today we are releasing Cloudflare OS, a chatbot with connectors, just like every other tech company is doing.
Except actually, it's different. This is a remake of Sandstorm[.]io, my startup from 10 years ago, except this time built on Cloudflare Workers (the platform I've spent the last 9 years building) and deeply leveraging AI. This is more or less the culmination of my secret 10-year master plan.
This is a full-on personal app vibe coding platform, in which the sandbox is so secure that you can pretty much go wild -- the AI cannot introduce a significant security bug. We believe a company's security team can feel comfortable giving non-technical users permission to vibe code and then sleep soundly at night.
How is that possible? It's the Sandstorm security model, revisited. A "Gadget" is the same thing as a Sandstorm "Grain": a fine-grained app instance. For example, if you have a document editor app, each document runs as a separate instance of the app, in a separate sandbox (one "Gadget").
This means two things, both of which I think are Big Deals: 1. The platform can manage all access control, by controlling who can access the Gadget at all. There is no way the Gadget can accidentally leak itself to an attacker -- even an attacker who has access to other Gadgets based on the same app. 2. Since everyone is running their own copy of the code, everyone can freely modify their copy of the code.
Think about #2 a bit more.
What if, when you wanted a new feature in the software you are using, you could just prompt your agent to add it?
This doesn't work in the cloud Software-as-a-Service model, because you are not running your own copy of the app.
Sandstorm tried to change that 10 years ago, but the world wasn't ready, because not enough people had the skills or patience to actually modify their software. AI has changed that. Now you just ask the agent -- the same agent that you are using to help you interact with the Gadget can also modify the code of the Gadget.
And it is so fun.
1. tinco · 1785942986 · focus · HN ↗
  This is really interesting. I built a similar product (not released yet), but it uses Kubernetes as the infrastructure layer instead of Cloudflare OS. I guess all these years later I am left with the same existential question that plagued Sandstorm. What is its relevance in the context of Linux containers? This is not a rhetorical question, is there a real benefit for a Sandstorm grain over a docker style Linux container? Does a containerized process not have all the same benefits of a Sandstorm grain, with the added benefit of not requiring any modifications of the containerized software?
  One argument I could bring is that despite all its claims, OpenAI still had to switch from containers to MicroVMs because its agents under test still managed to break out from their containers. Is the security model of a Sandstorm grain so much better that agents wouldn't figure out how to break out of it?
  1. kentonv · 1785943178 · focus · HN ↗
    Sandstorm's use of containers was just a means to an end. The real innovation was the fine-grained instances -- each document in its own container. No other container platform did that.
    But honestly, it didn't work well, because of cold start times and memory usage. It's bad enough when a server takes seconds to start, but if every document you open has a long startup time and uses hundreds of MB of RAM, it's really painful.
    Cloudflare OS doesn't use containers. It uses Dynamic Workers, which are 100x more efficient: <a href="https://blog.cloudflare.com/dynamic-workers/" rel="nofollow">https://blog.cloudflare.com/dynamic-workers/
    So the stuff I have been building in Workers for the past 9 years turns out to be the thing that Sandstorm needed all along. What a coincidence. :)
    valorzard · 1785952548 · focus · HN ↗
    dumb question: is this javascript/typescript only? can you use webassembly based languages instead?
    kentonv · 1785952947 · focus · HN ↗
    In theory Wasm could be supported, but generally JS/TS is much more efficient when running inside isolates (our lightweight sandboxes) since you don't have to bundle a language runtime into the app. CFOS at present only exposes JS (with TS coming soon).
    nullpoint420 · 1785994970 · focus · HN ↗
    Mmm so application-level sandboxing. Lovely.
    And I’m assuming your worker runtime is a process in a container on a shared node? What happens if the agent exploits your runtime?
    Does it get access to the whole container? VM? Node?
    Why should I ever choose this over MicroVMs? I have to design my architecture around your JS runtime. This isn’t an OS.
    teacpde · 1785999211 · focus · HN ↗
    Workers are in the same process but have separate heap, global vars, gc etc, the isolation is managed and achieved by V8. It is much lightweight compared to micro VM or containers. But the downside is you have to use JS because of V8.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.