Core Analysis¶

Project Positioning: celld’s core value is delivering the Cloudflare Workers + Durable Objects programming model to self-hosted environments by making each object a standalone SQLite database and using S3-compatible object storage CAS leases for ownership and replication. This addresses data-sovereignty, private deployment, and cost constraints while avoiding contention and single-point failures of a centralized DB.

Technical Features¶

• Object-level isolation: Each cell is an independent SQLite file, providing built-in sharding and reduced blast radius for failures.
• Consensus-free coordination: Ownership is enforced via object-storage compare-and-swap, avoiding Raft/Paxos and their operational burden.
• Replaceable nodes & durable recovery: Nodes can restore cell state from the bucket and resume execution, enabling transparent replacement.

Usage Recommendations¶

1. Validate object-storage semantics: Confirm your S3-compatible backend provides the required atomic write/visibility guarantees and acceptable latency before production.
2. Model by object: Design your app around cell-granularity state and avoid expectations of cross-cell transactions or global consistency.
3. Place nodes on trusted networks: Run celld nodes on private networks or encrypted overlays; do not expose peer ports publicly.

Important Notice: celld simplifies the consistency layer for operational ease but shifts correctness and availability dependence onto object-storage semantics and latency. Perform recovery and contention injection tests before production.

Summary: celld is a practical, operations-friendly solution when workloads fit object-granular sharding and teams require self-hosted Durable Objects semantics; it is not appropriate for applications demanding strong cross-object transactional guarantees.

Core Analysis¶

Core question: Migrating a Cloudflare Workers / Durable Objects project to celld involves code compatibility, deployment flow, object-store setup, and operational rehearsals.

Technical analysis & migration steps¶

1. Compatibility assessment: Audit Worker code to ensure it uses the celld-supported Durable Objects API subset. Identify and refactor logic that depends on cross-object transactions or global consistency (e.g., multi-object transactions).
2. Bundle & deploy: Install esbuild locally and run celld deploy . --bucket s3://my-cells-bucket to upload deployment artifacts. Verify deploy/current.json is correctly written to the bucket (fleet nodes load this deployment).
3. Object store & credentials: Use a dedicated S3 bucket and least-privilege credentials for celld. Validate CAS/overwrite semantics and upload/visibility latency.
4. Network & security: Advertise addresses only on a private network or encrypted overlay; secure distribution and rotation of fleet/peer-auth.json keys.
5. Node rollout & testing: Start multiple celld nodes and run end-to-end functional tests, performance benchmarks, and failure-injection tests (migration, node restarts, lease contention).
6. Rollback plan: Prepare rollback strategies and backups to revert to managed service or previous storage if necessary.

Practical tips¶

• Rehearse in non-production, focusing on high-write contention and lease-competition scenarios.
• Monitor replication latency, migration frequency, and errors to tune replication cadence and watermarks.
• For single-object hotspots, design sharding or introduce an external strong-consistency store as needed.

Important Notice: Migration is not just a drop-in swap; it often requires code refactoring to remove cross-cell transactional assumptions and operational preparation for object-store and network security.

Summary: Migrating to celld preserves the Workers developer experience and enables self-hosting, but requires refactoring of transactional patterns, validation of object-store semantics, and thorough operational rehearsals to ensure a smooth cutover.

Core Analysis¶

Core question: Each cell is an independent SQLite file continuously replicated to the bucket. That choice determines the granularity and operational characteristics of persistence, recovery, and backup.

Technical Analysis¶

• Persistence model: The runtime state is an on-disk SQLite file that celld uploads to an S3-compatible bucket; the bucket is the durable source of truth.
• Recovery flow: When a cell is taken by a new node or wakes, the node downloads the SQLite file and resumes execution; recovery time is dominated by file transfer and SQLite load time.
• Factors affecting recovery latency:
  1. Replication cadence: The interval between local writes and uploads defines the data loss window (RPO).
  2. Object-store visibility & propagation: Backends with eventual consistency or multi-region replication add visibility latency.
  3. File size & IO: Large SQLite files increase upload/download and parsing overhead.
  4. Network bandwidth/latency: Transfer times between nodes and bucket affect RTO.

Practical Recommendations¶

1. Tune replication to RPO/RTO: Increase upload cadence for critical/high-write cells or implement application-level checkpoints.
2. Shard to avoid hotspots: Break high-write workloads into multiple cells to avoid a single SQLite bottleneck.
3. Choose & validate backend: Pick an object store with low latency and expected semantics; measure upload/download time.
4. Backup practices: Snapshot important cells periodically and store them redundantly if supported; rehearse restores.

Important Notice: Continuous replication simplifies operations but is not a substitute for a designed, strongly consistent backup strategy for critical data. Measure and tune replication cadence, storage semantics, and network to meet production RPO/RTO.

Summary: celld’s per-cell SQLite model simplifies backup and recovery at object granularity, but recovery latency and data loss windows depend on replication cadence, object-store semantics, and network—so tune accordingly.

Core Analysis¶

Core question: celld’s performance and scaling are shaped by its design of per-cell SQLite files, periodic replication to object storage, and consensus-free coordination—this gives clear tradeoffs across workload patterns.

Technical Analysis¶

• Natural sharding: Objects map to cells, enabling capacity scaling by adding nodes and cells without shared DB contention.
• Single-cell limits: SQLite has write locking characteristics that make a single cell a bottleneck under high concurrent writes; read-heavy or write-distributed workloads are more suitable.
• Cold/hot management costs: Idle cells hibernate to save resources, but frequent wakes/migrations cause significant upload/download IO and latency.
• Replication & recovery effects: Replication frequency, object-store latency, and network bandwidth determine failover performance and throughput.

When to use¶

• Suitable:
• Many small state objects with dispersed writes.
• Private deployments needing fine-grained isolation and replaceable nodes.
• Not suitable:
• Single-object (single-cell) high concurrent writes (hotspots).
• Workloads requiring cross-cell atomic transactions or strict global consistency.
• Low-latency, sustained high-throughput write demands.

Practical guidance¶

1. Avoid hotspots: Choose shard keys to spread write load, or move hot write fields to an external strong-consistency store.
2. Tune watermarks & hibernation: Configure resident-cell high/low watermarks to balance memory and migration overhead.
3. Benchmark for capacity planning: Perform load tests against your chosen object store to measure replication latency, throughput, and recovery times.

Important Notice: celld is designed for dispersed, shardable state. Hotspot-prone or cross-object-consistent workloads require additional architecture or alternate systems.

Summary: celld scales well for many-small-object, distributed-write workloads; single-cell hotspots and global transactional needs are its weak spots.

Core Analysis¶

Core question: celld enforces single ownership by writing lease objects to object storage and using the object-storage compare-and-swap semantics instead of Raft/Paxos. The bucket becomes the only coordination plane.

Technical Analysis¶

• Mechanism: Nodes atomically CAS a lease object; the successful writer becomes the owner. Leases include versions and TTL-like information to support migration and heartbeating.
• Benefits: Avoids complex membership protocols, a control plane, and leader election operational overhead; nodes can discover and contest ownership directly via the bucket.
• Limits & Risks:
• Dependency on object-storage semantics: If the backend does not provide strong CAS/overwrite semantics under concurrency/latency, double-ownership or lost updates may occur.
• Visibility latency & recovery window: Lease propagation and replicated SQLite upload latency influence failover speed and possible data loss window.
• Security & clock issues: HMAC key compromise, clock drift, or replay risks can weaken ownership guarantees.

Practical Recommendations¶

1. Validate backend: Run high-concurrency and latency-injection tests against your S3-compatible service to confirm CAS/overwrite behavior and consistency model.
2. Shorten replication cadence: Tune celld’s replication frequency to reduce recovery windows, balanced against IO cost.
3. Operational hardening: Protect fleet/peer-auth.json, ensure NTP sync, and restrict bucket credentials to minimum privileges.

Important Notice: This is a pragmatic engineering tradeoff, not a full substitute for distributed consensus. Applications requiring strict cross-cell consistency or extreme partition tolerance should treat this carefully.

Summary: celld’s CAS-on-object-storage approach provides lightweight ownership coordination and operational simplicity for teams that accept the storage-backend dependency; it is not a drop-in replacement for strong consensus-based correctness guarantees.