celld Replaces Raft With a Single S3 API Call

On August 5, 2026, Ryan Dahl — the guy who created Node.js and then, a decade later, decided Node.js had made enough mistakes to justify creating Deno — posted a link to a new repository with a description almost nobody expected from him: a self-hosted clone of one of Cloudflare's most proprietary, most architecturally interesting products.

The repo is denoland/celld, and its one-line pitch is blunt: "self-hosted, distributed Durable Objects." If you've built on Cloudflare Workers, you know Durable Objects as the thing that makes Cloudflare's platform feel like it's cheating physics — a single-threaded, strongly-consistent, stateful compute primitive that lives at the edge, backed by its own SQLite database, addressable by name from anywhere in the world. It's genuinely one of the more clever pieces of infrastructure shipped in the last few years. It's also completely proprietary. You cannot run it yourself. You cannot inspect how it schedules ownership across Cloudflare's fleet. You are, structurally, locked in.

celld is Dahl's answer to that lock-in, and it's already been covered by The Register under the headline "Node.js creator liberates Durable Objects from Cloudflare," picked up by Hacker News, and written up independently by developer bloggers within a week of launch. It's early — version 0.1.0, explicitly alpha, Apache 2.0 licensed — but it's the kind of early that's worth reading closely, because the interesting part isn't "we cloned a Cloudflare product." The interesting part is what Dahl deleted to make it work.

What celld actually does

At the surface level, celld is a daemon you run on your own machines that lets you deploy code written against the Cloudflare Workers and Durable Objects JavaScript APIs — without Cloudflare. You write a Worker the same way you'd write one for Cloudflare's platform, bundle it, and point celld at it. The daemon embeds V8 to actually execute your JavaScript, and every Durable Object your code creates becomes its own independent SQLite database on disk.

That last detail is the part worth sitting with. Durable Objects, in both Cloudflare's version and Dahl's reimplementation, aren't rows in a shared database — each object (a chat room, a user session, a game match, a tenant) gets its own SQLite file. As the project puts it, this means "applications shard by construction — the contention and blast-radius failures of one shared database are designed out, not managed." You don't tune connection pools or worry about noisy-neighbor lock contention on a shared Postgres instance, because there is no shared instance. There's one SQLite file per object, and SQLite is very good at being the only writer to a single file.

Installation is a one-line curl-to-shell script (curl -fsSL https://celld.dev/install.sh | sh), and deployment leans on esbuild for bundling Worker code and the standard AWS credential chain for talking to object storage. The object storage part is where things stop looking like "a Cloudflare clone" and start looking like a genuinely different design.

How it works: firing the consensus layer

Here's the standard playbook for building a distributed system where exactly one node is allowed to "own" a piece of state at a time — a database shard, a lock, a Kafka partition, a Kubernetes leader election. You stand up a consensus service. Raft or Paxos via etcd, ZooKeeper, or Consul. You run an odd number of nodes so you can form a quorum. You implement (or more likely, import) a failure detector so the cluster can tell a dead node from a slow one. You handle split votes, network partitions, and the eternal question of what happens when the network is asymmetric — node A can reach node B, but B can't reach A.

celld doesn't do any of that. According to the project's own description, its nodes "coordinate through that bucket alone, with no control plane and no consensus." The bucket is an S3-compatible object store (or Google Cloud Storage), and the mechanism holding the whole system together is a single primitive: compare-and-swap.

Every object in the system — celld calls them "cells" — is addressable by name and replicated into the bucket. When a node wants to own a cell (to run the Durable Object's code and serve requests for it), it performs a compare-and-swap write against that object's location in the bucket. Object storage CAS guarantees that exactly one writer can win that operation. Whoever wins the CAS owns the cell. There's no membership protocol to join, no failure detector polling heartbeats, no quorum to assemble. The bucket's own atomicity guarantee is the coordination protocol.

When ownership needs to move — because a node died, because you're rebalancing load, because a node is under memory pressure and wants to shed cells — the new owner just pulls the cell's SQLite database out of the bucket and resumes. The bucket isn't a cache in front of a "real" database; it is the source of truth. Nodes are, in the project's framing, disposable. Lose one, and whatever cells it owned simply get reacquired by CAS from whichever bucket state was last durably written.

This is the actual engineering claim worth paying attention to, more than "runs Cloudflare Workers on your own hardware." Distributed systems have spent two decades building increasingly sophisticated consensus machinery — Raft's leader election, Paxos's proposal numbers, ZooKeeper's ephemeral znodes — specifically to solve the "who owns this thing right now" problem. celld bets that for a certain shape of workload, S3's CAS semantics (or any object store that offers atomic conditional writes) already solved that problem, and building a bespoke consensus layer on top is solving it twice.

Memory pressure and cell shedding

Because celld runs on your own hardware rather than an effectively-infinite edge fleet, it has to actively manage how many cells (and how much SQLite state) any one node holds in memory. The mechanism is tiered:

• At 80% of configured memory (tunable via CELLD_MAX_RSS_MB), the node starts shedding pressure.
• At 95%, that becomes a hard cap the process won't exceed.
• Under pressure, the node picks its least-recently-used idle cells, durably replicates them to the bucket, fences them (so no stale writes can leak through after eviction), and publishes them as unowned — without resetting their epoch, which is what lets another node pick them back up cleanly later.

The economic claim that falls out of this is that inactive cells "cost nearly nothing" — they're just files sitting in object storage until something reactivates them, which is the same value proposition that made Cloudflare's Durable Objects and, more generally, the whole serverless category attractive in the first place: you pay for activity, not for idle capacity sitting around waiting.

What changed versus what came before

The category celld sits in — durable, addressable, stateful compute units that coordinate across a fleet — isn't new. Cloudflare's Durable Objects popularized the pattern; virtual-actor frameworks like Microsoft Orleans and Akka have offered similar guarantees on your own infrastructure for years; and durable-execution platforms like Temporal and the newer Restate solve an adjacent problem (long-running, retriable workflows) with their own coordination machinery. What all of those predecessors share is that somebody is running a consensus or membership service under the hood — Orleans has its cluster membership provider, Akka Cluster runs a gossip protocol, Temporal leans on its own persistence and task-queue layer.

celld's pitch is that you can get Durable-Objects-shaped guarantees — single-writer state, automatic failover, addressable-by-name — from a fleet of stateless-feeling nodes and nothing but an S3 bucket. No dedicated coordination service to operate, patch, and reason about separately from your application nodes. If it holds up under real production load, that's a meaningful reduction in the amount of other infrastructure a team has to run just to get strongly-consistent stateful compute.

The other change is licensing and control. Cloudflare Durable Objects are only available if you're on Cloudflare's platform, priced on Cloudflare's terms, and observable only to the extent Cloudflare's dashboards let you observe them. celld is Apache 2.0. You can read the code that decides cell ownership. You can run it on bare metal, in your own cloud account, against MinIO if you don't want to touch S3 at all. That's the "liberates Durable Objects from Cloudflare" framing The Register used, and it's accurate as far as it goes — with the significant caveat that you're now the one operating it.

Why developers should actually care

The honest pitch for celld isn't "Cloudflare is bad." Durable Objects are a well-regarded product precisely because Cloudflare operates the hard parts for you. The pitch is for teams who already felt the tension of building on a proprietary primitive they liked but couldn't take with them — the classic serverless lock-in problem, except sharper here because Durable Objects don't have an obvious open equivalent the way, say, S3-compatible storage does for object storage.

A few concrete angles:

• Cost at scale. Dahl's own announcement claimed the self-hosted approach is "an order of magnitude cheaper at scale" than the managed offering. That's a claim from the project's creator, not an independently verified benchmark — nobody has published third-party numbers yet — but it's directionally believable for the same reason self-hosting almost anything is cheaper once you're big enough to amortize the operational overhead: you're paying for your own hardware and an S3 bill instead of a managed-service margin.
• Portability. Code written against the Workers/Durable Objects API is the same code whether it's running on Cloudflare or on your own celld fleet. That's a real hedge against lock-in for teams building on that API surface today.
• Operational simplicity, maybe. Removing a dedicated consensus service from your stack is a genuine simplification — one less stateful system to operate, patch, and page on. Whether celld itself is simpler to operate than what it replaces is a separate question, and one the project hasn't been around long enough to answer.
• Security posture is explicitly unresolved. The project ships separate "limitations" and "security" documentation pages rather than folding those caveats into the main README, which is the kind of signal worth reading as "we know this isn't done" rather than glossing over it.

Practical use cases

Where would you actually reach for this? The shape of workload Durable Objects were built for is the shape celld targets too: per-entity state that needs strong consistency without a shared database bottleneck. Concretely:

• Multiplayer or collaborative backends — one Durable Object per game room, per document, per whiteboard session, each with its own SQLite state and no cross-tenant contention.
• Per-tenant data isolation — SaaS products where each customer's state genuinely benefits from being its own database file rather than a row-level-security slice of a shared one.
• WebSocket session coordination — chat rooms, presence systems, live collaboration cursors — anything where you want a single strongly-consistent actor coordinating a set of connections.
• Edge-adjacent state for teams that can't or won't use Cloudflare — regulated industries, specific data-residency requirements, or organizations already committed to a different cloud that still want the Durable Objects programming model.

What the hype leaves out

A few things worth weighing before treating this as production-ready infrastructure:

It's alpha software, ten days old at the time of writing. Version 0.1.0. General reporting on the launch has been explicit that nobody should be moving an important production system onto it yet. That's not a knock — it's exactly what you'd expect from a project this new — but it's easy to lose in the excitement of a well-known name shipping something clever.

No published benchmarks. The "order of magnitude cheaper" and durability claims come from the creator's own announcement, not from an independent load test or a documented methodology. Cost comparisons against Cloudflare's actual managed pricing haven't been published by the project either. Treat the performance and cost story as a hypothesis the project is inviting you to test, not a settled fact.

S3 CAS latency becomes your coordination latency. If every ownership transfer requires a round trip to object storage, the latency characteristics of your bucket provider directly become the latency characteristics of your failover path. That's a very different operational profile than an in-memory gossip protocol or a co-located Raft cluster, and it's not yet clear from public material how that behaves under high cell-churn workloads (lots of small, short-lived objects moving ownership frequently) versus the steadier-state workload the design seems optimized for.

Rehydration cost on ownership transfer. Moving a cell means pulling its SQLite database out of the bucket before the new owner can resume it. For small objects that's presumably fast; for cells that have accumulated a large SQLite file over time, that's a cold-start tax every time ownership moves — during a node failure, a rebalance, or memory-pressure shedding. The project's docs don't currently quantify this.

"LTX" is part of the stack but undocumented in the README. Dahl's own announcement lists the stack as "V8 + S3 + SQLite + LTX + Tokio," but the public README doesn't explain what LTX is doing in that pipeline. For a project asking developers to trust it with stateful, durable data, an unexplained component in the durability path is worth watching for follow-up documentation rather than assuming.

You're trading one dependency for another. This is the least-discussed point in the coverage so far. celld frees you from Cloudflare, but the entire coordination model is now load-bearing on your object storage provider's compare-and-swap semantics behaving exactly as specified, under concurrent access, under failure. That's a reasonable bet — S3-compatible CAS is well-understood — but "no consensus" doesn't mean "no dependency," it means the dependency moved from a bespoke coordination service to your bucket provider's atomicity guarantees. If your object storage has a bad day, so does your cell ownership.

How it stacks up

An independent read

What makes celld worth writing about isn't that it reimplements a Cloudflare product — plenty of "open alternative to X" projects launch and go nowhere. It's that the reimplementation reveals a genuinely interesting bet: that a meaningful slice of what consensus protocols exist to do — establishing single ownership of a resource across an unreliable network — can be delegated entirely to a primitive (object-storage CAS) that most teams already have access to and don't think of as a coordination service at all. If that bet generalizes, it's a small but real shift in how people build the "who owns this shard right now" layer of distributed systems, away from bespoke consensus software and toward leaning harder on primitives cloud object stores already expose.

The skepticism worth holding onto is proportional to how new this is. A one-line announcement thread and a README are not a production track record, and the loudest claims in Dahl's launch post — the cost multiplier, the durability guarantee — are exactly the claims that haven't been independently tested yet. Object-storage CAS as a coordination primitive is a legitimate technique (it shows up in other systems that need lightweight leader election without a full consensus stack), but "legitimate technique" and "battle-tested at the scale and churn rate Cloudflare actually serves" are different bars, and celld has only cleared the first one so far.

Who should try it, and who should wait

Try it now if you're evaluating architecture for a greenfield project, you like the Durable Objects programming model, and you have the appetite to run alpha infrastructure with eyes open — ideally on a non-critical service where you can tolerate rough edges and want to give upstream feedback while the design is still moving.

Watch, don't adopt yet, if you're already running production workloads on Cloudflare Durable Objects and the appeal is portability. The migration story only matters once celld has a stable release, published benchmarks, and enough real-world runtime to have found (and fixed) its sharp edges — none of which exist yet.

Ignore it for now if your actual problem is long-running workflow orchestration rather than low-latency stateful actors — that's Temporal or Restate's territory, not this one — or if you have zero appetite for self-hosting distributed infrastructure, in which case the entire value proposition (control over your own fleet) works against you rather than for you.

What's genuinely worth tracking over the next few months is whether the "no consensus, just CAS" model holds up once independent operators start running it under real, adversarial-network conditions — high cell churn, flaky bucket connectivity, concurrent contention for the same cell from multiple nodes at once. That's the test Raft, Paxos, and every consensus protocol before them had to pass before anyone trusted them in production. celld hasn't taken that test yet; it's just proposed a shorter one.

If you've built on Cloudflare Durable Objects, or run your own actor-model infrastructure with Orleans or Akka: does removing the dedicated consensus layer in favor of object-storage CAS feel like a genuine simplification to you, or does it just relocate the hard distributed-systems problem somewhere less visible?

Sources:

• denoland/celld on GitHub
• celld/README.md
• celld.dev — project site
• Ryan Dahl's announcement thread on X
• Node.js creator liberates Durable Objects from Cloudflare with celld — The Register
• Celld: Self-hosted, distributed Durable Objects — Hacker News discussion
• Cloudflare Durable Objects documentation