r/CloudFlare

I've been spending an unreasonable amount of time playing with Cloudflare's newer Containers stuff, and it eventually turned into a real project, so I figured this was probably the right subreddit to show it to. The basic idea is give humans and AI agents Linux machines on demand, but build as much of the control plane as possible on Cloudflare instead of standing up Kubernetes, EC2 fleets, a scheduler, Redis, Postgres, etc. Think roughly in the same problem space as E2B/Daytona/sandbox APIs, except this started as me asking: how far can I push Cloudflare's stack before I actually need traditional infrastructure?

A mainbrella "machine" is a Cloudflare Container controlled through Workers and Durable Objects. The API handles lifecycle, ownership, quotas, generations, execution, file operations, terminals, previews, etc.

Right now the API supports things like:

- starting/stopping isolated Linux workspaces

- multiple machine sizes

- running commands and longer-lived processes

- stdin, signals and PTYs

- binary file reads/writes

- filesystem operations

- reconnectable execution output

- browser terminals

- SSH

- outbound Internet access

- custom container images

- API keys

- protected web previews

- persistent/saved workspaces

- JavaScript and Python SDKs

- OpenAPI

The JS SDK is on npm as `@mainbrella/sdk` and the Python one is `mainbrella` on PyPI.

One thing I ended up caring about way more than I expected was **generation identity**. If an agent starts machine A, the machine dies, and another one appears with the same logical slot, I don't want some delayed request from the old generation modifying the new one. So operations carry the exact container generation and stale requests get fenced out. Similar story with creation: there are idempotency keys and reservations so an ambiguous network response doesn't casually turn into "cool, I guess I'll start another paid machine."

Durable Objects have been extremely useful for this. There's a `ContainerAccount` DO coordinating account-level reservations/concurrency, while individual container state stays associated with its runtime. D1 handles the account/billing/application data around that. It feels like a weird little distributed systems course hiding inside an AI sandbox product. Another fun piece is previews. An agent can start, say, a Next.js dev server inside its container and request a temporary protected URL. The preview gateway routes to the exact account/container/generation and supports normal browser traffic plus WebSockets/HMR.

So you can have an agent building a web app inside a private container, open the result in your browser, change code, and get the normal Next.js development loop without assigning the container a public IPv4 address. Saved workspaces were another rabbit hole. Normal stop can throw away the writable filesystem. But you can explicitly save a workspace, stop it, then restore those filesystem bytes into a fresh container later.

It isn't pretending to suspend Linux. RAM and processes don't magically come back. It's filesystem persistence with explicit save/restore semantics. I actually like that distinction because it's understandable and testable. We have tests for binary bytes, symlinks, permissions, timestamps, stale-generation fencing, account isolation, export, deletion, restore, etc. There is probably more verification code in this repo than is healthy.

### Can you run this yourself?

Yes, with an important qualification. **The MainBrella software is free/open source. You don't need to pay me anything to fork it and run your own version.** Cloudflare Containers themselves, however, currently require the $5/month Workers Paid plan. So I'm not going to claim Cloudflare gives you production Containers on a completely free account. If you already have Workers Paid, though, Cloudflare includes a chunk of Container CPU, memory and disk usage in that $5 base plan. For a small personal deployment, you may be able to experiment without paying anything *additional* for the compute. The repo includes the actual Wrangler configs, D1 migrations, Worker code, container runtime, Dockerfile, tests and deployment tooling.

I'd especially love feedback from people who know Workers/Durable Objects/Containers well:

**Am I abusing anything?**

Are there places where I'm building machinery Cloudflare already provides?

Would you structure the Durable Objects differently?

Is there some obvious Cloudflare primitive I should be using that I'm not?

And more broadly: does "a fairly complete AI sandbox/control plane implemented almost entirely on Cloudflare" seem like an interesting open-source direction?

Feel free to tear it apart. That's genuinely useful at this stage. Link in comment.