polvi Reading the alpha docs and code layout, the coordination story is narrower (and simpler) than "distributed Durable Objects" suggests, in a good way:
- Exactly-one-owner per cell is enforced with object-storage compare-and-swap on lease records (
crates/ltx/src/leaser.rs), not a membership protocol or consensus service. The bucket is the only authority. - Consequence spelled out in
docs/limitations.md: bucket credentials are fleet-administrator access, so scope them narrowly. There is no separate admin plane to compromise or to protect. - Peer HTTP is deliberately TLS-free and expects a private network/overlay; requests are HMAC-signed with
fleet/peer-auth.json, which the first node creates in the bucket, so trust also bootstraps from the bucket.
Useful mental model for operators: everything trusts the bucket, and only the bucket — placement, deploys (deploy/current.json), peer auth, and durability all reduce to S3 CAS + replication. Evaluating celld mostly means evaluating your object store's consistency and your credential scoping.