Celld: Cloudflare’s Best Idea, Unbundled
github.com/denoland/celld | License: Apache-2.0
A shared database starts as convenience and ends as politics. One noisy customer drags response times, one hot row serializes the whole app, and suddenly a simple multiplayer game, inbox, or support dashboard needs a PhD in contention management. Celld lands right on that pain. It runs Cloudflare-style Durable Objects on your own machines, but the interesting bit is not self-hosting for its own sake. The interesting bit is that every object becomes its own tiny database and compute unit, which feels much closer to how modern apps actually behave.
The Drop: Stateful Apps Kept Getting Cornered
Plenty of products want logic that sticks to a single identity, e.g. one chat room, one shopping cart, one document, one game lobby. That pattern sounds simple until infrastructure gets involved. Traditional app stacks split compute from storage, then spend years patching the gap with caches, locks, queues, and sticky sessions. Cloudflare Durable Objects fixed that elegantly, but only inside Cloudflare’s world.
Celld exists because that model is too good to stay captive. Teams want the same per-object statefulness without handing over placement, storage, and runtime control to one vendor. They also want something that can idle cheaply. A million mostly sleeping rooms or user sessions should not require a million always-on containers.
Deno’s answer is blunt: stop treating stateful coordination as a special case. Make each object addressable by name, persist its state in SQLite, and let inactive objects disappear until traffic wakes them back up. That cuts straight at the usual headaches, especially the blast radius that comes from centralizing everything in one giant database.
The Stack: Rust, V8, and Buckets Doing Control Plane Work
Under the hood, Celld is written in Rust, embeds V8 to run Cloudflare Worker-style JavaScript bundles, and stores each object as its own SQLite database. Replication and coordination ride on S3-compatible storage or Google Cloud Storage, with esbuild handling deploy bundling and object storage primitives doing the hard synchronization work.
The Sauce: Object Storage as the Brain
Here’s the architectural bet that makes Celld worth paying attention to: the shared bucket is not just backup storage, it is the fleet’s durable source of truth. Deployments live there, object state lives there, and tiny ownership records live there. Nodes do not depend on a separate coordinator, consensus cluster, or membership service. They coordinate through compare-and-swap operations in object storage, which gives exactly one node ownership of a cell at a time.
That sounds almost suspiciously minimal, but the design has teeth. Each named object, called a cell, owns its own SQLite database. A node can load a cell, execute requests against it, continuously replicate its state back to the bucket, then drop it when memory pressure rises or traffic disappears. Another node can later restore that database and continue execution. The machine is replaceable, the bucket persists the truth.
Honestly, the interesting part is not “Durable Objects, but self-hosted.” It’s that sharding by construction turns a scaling problem into an application shape. Instead of one database that needs heroic partitioning later, Celld starts with isolated little state islands. Contention stays local. Failures stay local. Cold objects cost nearly nothing. Even WebSockets fit this model because the runtime can keep connection ownership with the host while the object hibernates between messages.
There is a tradeoff, of course. Object storage is slower and stranger than a purpose-built consensus system. But for workloads built around named entities with bursty activity, that trade looks surprisingly rational.
The Move: Build Stateful Products Without Renting the Primitive
Founders and product teams should read Celld less as infrastructure trivia and more as product velocity. The repo gives a path to features that are painful in stateless stacks, e.g. collaborative rooms, persistent chat threads, AI session memory, multiplayer coordination, support conversations, device twins, and long-lived workflow instances. Each entity gets a stable execution context plus local storage, without standing up Redis, Postgres tuning, and a queueing maze just to keep state coherent.
A smart use case starts with something identity-shaped. Customer support inboxes are a great example. One conversation maps cleanly to one cell, message ordering becomes easier, and dormant threads stop burning compute. Real-time AI products are another. One agent session or one user memory capsule can live as a named object, wake on demand, and replicate durably to storage you already control.
Strategically, that means faster iteration on products where state itself is the moat. Instead of outsourcing the primitive to Cloudflare or rebuilding it from scratch, a team can own latency, data location, and economics. That matters if enterprise buyers care about residency, if margins matter, or if the product’s behavior depends on long-lived context.
The Aura: Users Start Expecting Software to Remember
People do not naturally think in stateless requests. They think in rooms, threads, projects, sessions, and relationships that persist even when nobody is looking at them. Celld lines software up with that mental model. A product built this way can feel less like hitting endpoints and more like returning to a place that kept its memory.
That expectation compounds. Once an app reliably remembers the state of a conversation, a game lobby, or an AI workflow without awkward refresh bugs or sync weirdness, forgetfulness starts to feel like bad product design, not an unavoidable engineering compromise.
The Play: Stateful Compute Becomes a Platform Wedge
From a VC lens, Celld looks like a better mousetrap in a large existing market, but one with 0-to-1 upside if self-hosted durable compute becomes a default app primitive. TAM spans edge platforms, backend orchestration, real-time collaboration infra, and enterprise deployments that want Cloudflare-like programming models without Cloudflare dependency. Early PMF signals are decent for a young infra repo, 3,512 stars, strong brand gravity from Deno, and a clear “why now” tied to AI sessions, multiplayer apps, and collaboration backends.
The moat is not raw code. It is execution speed, developer trust, and owning the mental model before competitors wrap it into managed products. If teams build app behavior around named stateful objects, switching costs rise because the application architecture itself starts depending on that shape.
Winners:
Liveblocks: Collaboration primitives get easier to self-host in regulated environments, and that expands from SDK value into infrastructure-adjacent product surface.
Fly.io: Stateful app deployment gets more compelling when object-local compute can run close to users on customer-controlled fleets, which deepens infrastructure stickiness.
Cloudflare: Durable Objects gain legitimacy as a category-defining abstraction, and wider adoption can still funnel serious workloads back to the managed original.
Losers:
Convex: Backend-as-a-service differentiation erodes when stateful coordination patterns become more portable, and adapting is hard without losing simplicity.
Supabase: Postgres-centric app architecture looks less sufficient for real-time entity-shaped workloads, which pressures expansion into more opinionated compute models.
MongoDB: General-purpose databases lose some architectural mindshare when developers stop starting from one shared state layer for every product problem.
tl;dr
Celld turns self-hosted infrastructure into a Durable Objects-style runtime where every named object carries its own SQLite state and can wake, move, and persist through object storage alone. The bucket-centric coordination model is the clever part. Teams building chat, collaboration, multiplayer, or AI session products should look closely.
Stars: 3,512 | Language: Rust
