Thanks for all the great work on celld! 馃檶
Context
We are evaluating celld as the stateful V8 profile for customer-authored workflow and agent code. We have read the current security and limitations pages and understand that today celld is explicitly not safe for hostile multi-tenant use, and that a fleet runs one application.
We are asking about the future direction so we build against the right trust boundary rather than guessing.
What we are comparing against
Cloudflare Durable Objects give us a useful reference for the isolation properties we care about:
- each object has one active single-threaded instance at a time;
- each object has private transactional storage exposed only to that object;
- input gates prevent new events from interleaving with pending storage reads;
- output gates delay external messages until pending storage writes commit;
- objects hibernate and migrate, with durable state surviving the move.
We are not asking celld to reproduce Cloudflare's full edge platform. We want to know which of these properties celld intends to guarantee as its own security model, and at what granularity.
The question
Which long-term deployment model should we build against?
- One trusted application per fleet, with the process or fleet as the trust cell.
- Hostile customer code is supported, but one celld process or fleet is the trust cell (we isolate each organization-level fleet under gVisor or Firecracker and keep network, secrets, and native tools behind external capabilities).
- Mutually hostile Workers sharing one celld process is an eventual goal.
For model 2, we can already contribute the outer isolation and capability layer ourselves. For model 3, we would want to know whether focused contributions around a sandbox-enabled celld build, sandbox conformance CI, and a rootless container profile would fit the project.
We are not requesting a control plane, scheduler, or account service. We want to avoid building against a security model celld does not intend to support.
What we can offer
If any of this is in scope, we can contribute focused, tested patches (via the git format-patch path) rather than broad proposals. We would start with the smallest useful unit and respect review time.
Thanks for all the great work on celld! 馃檶
Context
We are evaluating celld as the stateful V8 profile for customer-authored workflow and agent code. We have read the current security and limitations pages and understand that today celld is explicitly not safe for hostile multi-tenant use, and that a fleet runs one application.
We are asking about the future direction so we build against the right trust boundary rather than guessing.
What we are comparing against
Cloudflare Durable Objects give us a useful reference for the isolation properties we care about:
We are not asking celld to reproduce Cloudflare's full edge platform. We want to know which of these properties celld intends to guarantee as its own security model, and at what granularity.
The question
Which long-term deployment model should we build against?
For model 2, we can already contribute the outer isolation and capability layer ourselves. For model 3, we would want to know whether focused contributions around a sandbox-enabled celld build, sandbox conformance CI, and a rootless container profile would fit the project.
We are not requesting a control plane, scheduler, or account service. We want to avoid building against a security model celld does not intend to support.
What we can offer
If any of this is in scope, we can contribute focused, tested patches (via the
git format-patchpath) rather than broad proposals. We would start with the smallest useful unit and respect review time.