<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2" -->

---
title: Celld: self-hosted Durable Objects and Workers using S3...
description: Celld is an open-source daemon from Deno Land that enables running Cloudflare Workers and Durable Objects on self-hosted infrastructure. Each Durable Object...
canonical: https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Celld: self-hosted Durable Objects and Workers using S3 and SQLite | daily.dev
og:description: Celld is an open-source daemon from Deno Land that enables running Cloudflare Workers and Durable Objects on self-hosted infrastructure. Each Durable Object...
og:url: https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2
og:image: https://api.daily.dev/og/posts/VGLSddXk2.png
og:image:alt: Celld: self-hosted Durable Objects and Workers using S3 and SQLite
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Celld: self-hosted Durable Objects and Workers using S3 and SQLite

**[Collections](https://daily.dev/sources/collections)** · 3 min read · 8 upvotes · 0 comments

## Summary

Celld is an open-source daemon from Deno Land that enables running Cloudflare Workers and Durable Objects on self-hosted infrastructure. Each Durable Object gets its own SQLite database replicated to an S3-compatible bucket. Nodes coordinate through the bucket using compare-and-swap operations, requiring no control plane, consensus protocol, or membership service. Built in Rust with embedded V8, it accepts Wrangler config bundles and uses esbuild for Worker code. Peer communication is HMAC-authenticated and replay-protected, with TLS termination left to the operator. Available via curl script or Docker for Linux x86-64 and ARM64.

## Content

Ryan Dahl and Deno Land released [celld](https://github.com/denoland/celld), an open-source daemon that lets you run Cloudflare Workers and Durable Objects on your own infrastructure. It's version 0.1.0, Apache 2.0 licensed, and honestly pretty interesting if you've ever wanted the Durable Objects model without the Cloudflare bill.

## What Durable Objects actually are

A Durable Object is a worker process paired with its own local SQLite database. Writes are confirmed only after replication to off-machine storage, so state survives crashes. You get strong consistency without coordinating across replicas — each object is its own isolated unit.

celld implements the same model: one SQLite database per object (called a "cell"), replicated to an S3-compatible bucket using LTX. The bucket doubles as the coordination layer, so there's no separate control plane, no Raft cluster, no consensus service. Nodes coordinate exclusively through compare-and-swap operations on the bucket.

## Architecture

Built in Rust with V8 embedded, celld accepts Wrangler config bundles and uses esbuild for Worker code. The API is compatible with Cloudflare's Durable Objects, so existing wrangler configs work.

A few numbers from the 0.1.0 release:

- ~4 MB RAM per resident cell
- ~1,000 resident cells on an 8 GB node
- ~4 ms cell wake time
- ~90 ms durable write latency
- ~20 second failover

Idle cells hibernate automatically. The fleet shards by construction since each object is its own isolated database — no explicit sharding configuration needed.

Peer communication is HMAC-authenticated and replay-protected, but TLS termination is left to the operator. WireGuard or Tailscale are the suggested approaches.

## What's missing

This is an honest alpha. Missing APIs include KV bindings, R2 bindings, Queues, and Cron Triggers. Multi-tenant workloads have security constraints worth reading carefully before deploying. The project also has an unusual contribution model — pull requests are disabled, patches go to the maintainer by email.

## Installation

Linux x86-64 and ARM64 are supported, via a curl script or Docker image.

```bash
curl -fsSL https://celld.deno.com/install.sh | sh
```

## Cost comparison with Cloudflare

The project includes a candid cost comparison with Cloudflare's managed offering. At scale, self-hosting wins on price but you're taking on operational complexity — failover, storage costs, TLS, monitoring. At small scale, Cloudflare's free tier is hard to beat.

For teams already running their own infrastructure who want the Durable Objects programming model without vendor lock-in, celld is worth watching. It's early, but the architecture is clean and the performance numbers are reasonable for a first release.

## Questions this post answers

### What is celld and how does it let me self-host Cloudflare Durable Objects?

Celld is an open-source daemon from Deno Land, released at version 0.1.0 under Apache 2.0, that reimplements the Durable Objects model on your own infrastructure. Each object runs as a worker with its own SQLite database ('cell'), replicated to an S3-compatible bucket via LTX, which also serves as the coordination layer via compare-and-swap operations instead of a separate consensus service.

_Teams weighing Cloudflare lock-in against self-hosting can follow daily.dev for updates on tools like celld._

### What are the performance numbers for celld's 0.1.0 release?

The 0.1.0 release reports roughly 4 MB of RAM per resident cell, about 1,000 resident cells on an 8 GB node, roughly 4 ms cell wake time, about 90 ms durable write latency, and around 20 seconds of failover time. These figures come from an early alpha built in Rust with embedded V8, so they reflect a first-release baseline rather than a mature production system.

_Engineers benchmarking self-hosted Durable Objects setups can track performance updates on daily.dev._

### What features are missing from celld's alpha release?

The 0.1.0 alpha of celld lacks KV bindings, R2 bindings, Queues, and Cron Triggers, and multi-tenant deployments have security constraints that need careful review before production use. It also uses an unusual contribution workflow: pull requests are disabled, and patches must be sent to the maintainer by email instead.

_Anyone evaluating early-stage infrastructure tools like celld can follow daily.dev for maturity updates._

## Community take

How the wider developer community reacted, aggregated from 1 discussion and 42 comments across hackernews (as of 2026-09-13).

**TL;DR:** The community is broadly enthusiastic about celld as a meaningful step toward self-hosting Durable Objects outside Cloudflare, though several commenters raise practical concerns about S3 dependency, operational complexity, and cost compared to managed alternatives.

**Sentiment:** 55% positive · 30% mixed · 15% skeptical

**The case for**

- Using S3 CAS as the coordination layer is praised as a pragmatic choice that leverages infrastructure most orgs already have.
- V8 isolates mean no nested VM difficulties, so celld can run on shared or commodity hosting without bare metal.
- The SQLite-per-object model backed by litestream-style replication is seen as a powerful yet simple abstraction.
- Having multiple independent implementations of the Durable Objects model is welcomed, even by a Cloudflare engineer.
- Hibernation and sharding by construction keep idle costs very low.

**The pushback**

- S3 is effectively the control plane and consensus layer, so correctness depends on S3's strong-consistency guarantees — which not all compatible stores provide.
- No local-only mode makes quick prototyping and experimentation harder without configuring object storage first.
- Running a self-hosted distributed fleet (e.g., on EKS local zones) can be far more expensive than paying for managed Durable Objects on demand.
- Cloudflare's global reach and per-request pricing are hard to replicate with self-hosted infrastructure.
- The no-pull-requests / email-patch policy drew skepticism and jokes about whether the codebase itself was AI-generated.

**By community**

- hackernews (positive): Broadly enthusiastic about the architecture and the freedom from vendor lock-in, with substantive debate around S3 dependency, cost trade-offs, and the no-PR contribution policy.

**Hottest debate:** Whether delegating coordination to S3 CAS truly eliminates the control plane or merely pushes it down to a black-box dependency whose consistency guarantees vary by provider.

**Open questions**

- Does celld require S3 strong consistency to be correct, or does any S3-compatible store suffice?
- What would a realistic self-hosted workerd with Durable Object support look like without NFS?
- Could a local filesystem or in-memory mode be added for easy prototyping without configuring object storage?
- Will the no-pull-requests policy become a broader trend among open-source maintainers worried about low-context AI-generated patches?

**Highlights**

> You beat us to it! Been meaning to land this but got distracted. https://github.com/cloudflare/workerd/pull/6780 But honestly I love that there are multiple implementations now.
> — [kentonv on hackernews · 1 comments](https://news.ycombinator.com/item?id=49190321)

> Honestly, you wouldn't want to run our internal implementation -- it's far too complicated. Unless you have 100+ datacenters around the world -- then maybe. The goal of this new design is to scale to a cluster while being operationally very easy to set up. Ideal for self-hosting. NFSv4 is an easy first step, convenient because it's broadly understood, has many implementations, and requires no client libraries. I could imagine a follow-up to support LiteFS instead of NFS could make a lot of sense, though it'll get more complicated. But yes, celld is definitely ahead of us here. No doubt about that.
> — [kentonv on hackernews](https://news.ycombinator.com/item?id=49191649)

> on the one hand, hosting is hard, you should pay people to host, especially distributed systems. on the other hand, deno land folks stole from (used open source from) the best. the coordination layer/control-plane is all S3 CAS of dumb json files, which is a fantastic common-mode infra requirement for most orgs anyways, & perhaps a durable control-plane substrate you'd feel comfortable having someone else run (such as aws or others), while you run the data-plane (workers) yourself. and then for the durable objects themselves, they used litestream, which is a pretty top pick, excellent way to get radical distribution (but actual topology not included, some assembly required)! https://hn.algolia.com/?q=litestream there's no reason this wouldn't run fine on most hosting, you definitely don't need bare metal. the virtues of v8 sandboxing / isolates! no need for vm's at all, no nested vm difficulties if you are trying to host on a shared host! but if you're asking questions like this, i want to again point you back to my top point.
> — [jauntywundrkind on hackernews](https://news.ycombinator.com/item?id=49189393)

> > addressed by name and replicated to an S3-compatible bucket you own; nodes coordinate through that bucket alone, with no control plane or consensus ... but that S3 _is_ the control plane and consensus layer, no? You're just pushing this down the stack to whoever runs that S3 clone.
> — [q3k on hackernews · 1 comments](https://news.ycombinator.com/item?id=49189018)

> Wonder if this will become common practice from now on ?   > Pull requests are disabled. Coding agents make it too easy to send a large,    > low-context change that costs maintainers more time than it saves.    > Thoughtful contributions are welcome; please understand the code,    > keep the patch focused, and respect the review time you are asking for.   >    > Send a git format-patch attachment to ...
> — [sakesun on hackernews · 3 comments](https://news.ycombinator.com/item?id=49191058)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=49185430) · 237 points · 42 comments

## Similar posts on daily.dev

- [Node.js creator liberates Durable Objects from Cloudflare](https://daily.dev/posts/node-js-creator-liberates-durable-objects-from-cloudflare-y12vjttqy) · DEVCLASS · 0 upvotes · 1 comments

---

Tags: [#rust](https://daily.dev/tags/rust), [#cloudflare](https://daily.dev/tags/cloudflare), [#sqlite](https://daily.dev/tags/sqlite)

[View this post on daily.dev](https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Celld: self-hosted Durable Objects and Workers using S3 and SQLite","url":"https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2"},"datePublished":"2026-08-06T06:56:40.332Z","dateModified":"2026-09-13T19:43:41.327Z","description":"Celld is an open-source daemon from Deno Land that enables running Cloudflare Workers and Durable Objects on self-hosted infrastructure. Each Durable Object...","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":8},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust,cloudflare,sqlite","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"Celld: self-hosted Durable Objects and Workers using S3 and SQLite"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/celld-self-hosted-durable-objects-and-workers-using-s3-and-sqlite-vglsddxk2#faq","mainEntity":[{"@type":"Question","name":"What is celld and how does it let me self-host Cloudflare Durable Objects?","acceptedAnswer":{"@type":"Answer","text":"Celld is an open-source daemon from Deno Land, released at version 0.1.0 under Apache 2.0, that reimplements the Durable Objects model on your own infrastructure. Each object runs as a worker with its own SQLite database ('cell'), replicated to an S3-compatible bucket via LTX, which also serves as the coordination layer via compare-and-swap operations instead of a separate consensus service. Teams weighing Cloudflare lock-in against self-hosting can follow daily.dev for updates on tools like celld."}},{"@type":"Question","name":"What are the performance numbers for celld's 0.1.0 release?","acceptedAnswer":{"@type":"Answer","text":"The 0.1.0 release reports roughly 4 MB of RAM per resident cell, about 1,000 resident cells on an 8 GB node, roughly 4 ms cell wake time, about 90 ms durable write latency, and around 20 seconds of failover time. These figures come from an early alpha built in Rust with embedded V8, so they reflect a first-release baseline rather than a mature production system. Engineers benchmarking self-hosted Durable Objects setups can track performance updates on daily.dev."}},{"@type":"Question","name":"What features are missing from celld's alpha release?","acceptedAnswer":{"@type":"Answer","text":"The 0.1.0 alpha of celld lacks KV bindings, R2 bindings, Queues, and Cron Triggers, and multi-tenant deployments have security constraints that need careful review before production use. It also uses an unusual contribution workflow: pull requests are disabled, and patches must be sent to the maintainer by email instead. Anyone evaluating early-stage infrastructure tools like celld can follow daily.dev for maturity updates."}}]}
```

