Cloudflare deployment

The production backend for datadata today is Cloudflare Workers with Durable Objects. It’s a natural fit for the model: a folder needs exactly one authority that orders its events, and a Durable Object is exactly that — a single-threaded instance with its own storage, addressable by id.

The shape

• One Durable Object per folder. The DO embeds the datadata server, so event ordering is free: there’s only one thread that could be ordering them.
• SQLite storage in the DO via the storage adapter — document snapshots, the append-only event log, and Yjs state, colocated with the compute.
• WebSockets to clients. Browsers connect to the DO directly; the WebSocket event bus tracks per-connection subscriptions and broadcasts to exactly the subscribers of each document.
• Auth at the door. Clients present a token (user, folder, expiry) minted by the host application; the DO validates it before accepting the connection. What a user may do inside the folder is currently the application’s problem — see Limitations.
• Agents in the DO. Server-side agents attach as in-process clients inside the same DO, sharing the folder with WebSocket users via the composite event bus.

Properties that fall out

• Region-local consistency — a folder lives where Cloudflare places its DO; all writes serialize there.
• Scale-out by folder — thousands of folders mean thousands of small, independent DOs, not one big server. The flip side: a single folder’s throughput is bounded by its single DO.
• Hibernation-friendly costs — idle folders cost nothing.

Not Cloudflare-only by design

The server core has no Cloudflare dependency — Durable Objects are the current backing, chosen because the per-folder authority model maps cleanly. The seams (storage adapter, event bus) are where another backend would plug in; none exists yet.