Very similar to an existing Cloudflare library vibe-sdk. Runs an agent in the Durable Object and spins up a container if the agent needs to execute a bash command. The container can even mount the SQLite based object store as a filesystem to perform filesystem operations. https://github.com/cloudflare/vibesdk
To solve the networking setup, typically some sort of "slirp" is needed. Slirp on one hand takes (fake or real) packets from somewhere and then on the other side pass it to a normal Linux process that does CONNECT / BIND / SEND / RECV.
It turns out you can do all the packet processing magic (connection tracking, syn handling, etc) in userspace totally fine, and then indeed hand it over this to userspace syscalls.
Being upset with classic C-based slirp and rust smoltcp (not enough features) I've dug up Fuchsia userspace tcp/ip stack - netstack - and wrapped it in slirp a-like envelope.
So this beast is basically that - on one hand you pass it packets (potentially from inside container) on the other hand it does connect/bind/etc to host OS.
This approach, in one form or another, is used by tailscale, podman and many other container runtimes.
It's designed for container running, but ArtifactFS has some similarity in principle to me. The on-demand materialization. Quote: ArtifactFS is a Git-backed filesystem daemon (FUSE driver) in Go that mounts repositories as normal working trees while avoiding eager blob downloads.https://github.com/cloudflare/artifact-fs
I threw together my own jujutsu powered FUSE subtree project just the other night. This was basically one-shotted, just to see how it does it, to learn more, not really intended for use. But obvious overlap. https://github.com/rektide/jj-workfuse
Hi Cloudflare people, if you are reading this. Please clean up your Cloudflare. Skills. There are way too many skills for the platform. You should consolidate all of your skills into a single skill and route everything thru that skill. The way it is right now pollutes our context window.
A few months ago now I started adding seccomp sandboxing to jinja2rs and then liboverlayfs support to ansiblers (which are early Rust ports).
Haven't finished that, but
I started working on a VM format that stores signed machine state into an OCI container repository, using the hypervisor migration support of KVM/QEMU.
Though this is not safe yet if ever, VM migrations are probably another way to sandbox and deploy en masse.
> At this time, we are not seeking outside contribution.
> AI has made writing code easy. The hard part, today, is not writing the code, but reviewing it, making sure quality stays high, and keeping the product coherent. In that light, unfortunately, external code contributions are "donating" the easy part of the job, while creating more of the hard work.
Feels very weird, but is logically sound: owners know exactly what they want and so they can work with Claude et al to iterate on features faster than with most drive-by contributors.
It reads like an "end of an era" but I imagine the steady state will be somewhere in the middle: high trust, high context contributors will still be able to contribute meaningful work.
workerd stand-alone is designed to work well at small-medium scale.
If we open sourced Cloudflare's production scheduler, nobody would be able to use it because it is explicitly designed for HUGE, globe-spanning scale. Well, nobody except our direct competitors.
But the goal with workerd is actually that it should be pretty easy to run, about as easy as Node. Stateless workloads should scale trivially (just add more instances and load balance). For Durable Objects (statefull), currently it doesn't scale well at all, but I'm working on changes[0] so that it scales nicely across a cluster. I intentionally chose a design here that is operationally easy to set up. (Basically: just connect all the nodes to NFSv4.)
Interesting bit from the repo: there is an agent's plan (presumably unintentionally) checked in two days ago as part of a rewrite from the Vercel AI SDK to pi-agent-core (https://github.com/cloudflare/cloudflare-os/blob/main/plans/...). That plan states "The project is in early alpha — minor behavioral regressions are acceptable and will be fixed as discovered.".
It looks like this product uses pi-agent directly (https://github.com/cloudflare/cloudflare-os/blob/main/plans/...). How come Cloudflare is not using their homegrown Agents SDK / Think / Flue harness for this? I am asking genuinely as I am evaluating a harness to build my agent platform.
wrangler is a development tool. You wouldn't want to run dev mode in production.
But workerd can be used directly without wrangler, and is production-capable in that format.
Unfortunately we did not have time to put together example configs for this before launch (I wish we could have delayed, it was out of my hands), but we will be doing so soon.
It's the same code. The only thing it doesn't include is the global scheduling and orchestration, but you don't actually want that locally. (And honestly... that stuff is a bit of a beast.)
Durable Objects are fully supported by workerd (and Cloudflare OS uses them extensively).
There is, however, one catch currently: Durable Objects don't scale out well without the global scheduling. For running Cloudflare OS for one user, this is actually no big deal, but a company-wide instance might not work well.
This is not a traditional computer operating system. We use the term "operating system" in two senses:
An operating system for the company to be productive with AI, in a way that is safe, so that the security team can sleep at night.
An operating system for AI workloads, analogous to the sense in which a traditional operating system manages compute workloads.
