Los Durable Objects de Cloudflare resolvieron un problema difícil —estado consistente y direccionable por nombre, distribuido— a cambio de atarte a su plataforma. El 5 de agosto de 2026, Deno publicó celld, un daemon open source que promete lo mismo pero corriendo en tu propia infraestructura, y con una decisión de diseño que llama la atención: usa un bucket compatible con S3 como única capa de coordinación. Sin Raft, sin control plane, sin servicio de consenso. En esta review lo desarmamos: qué es, cómo funciona esa coordinación por S3, qué rinde, qué cuesta y —sobre todo— dónde todavía no llega.
celld es un daemon open source de Deno, publicado el 5 de agosto de 2026 bajo licencia Apache-2.0, que ejecuta Cloudflare Workers y Durable Objects en tus propios servidores. Cada objeto es una base SQLite (una "celda") y los nodos se coordinan a través de un bucket compatible con S3 usado como única fuente de verdad: sin control plane, sin consenso y sin Raft. Está escrito en Rust sobre Tokio y su versión actual es la v0.1.0 (alpha).
¿Por qué querrías sacar los Durable Objects de Cloudflare?
Porque querés control sobre dónde vive tu estado y quién define tus dominios de falla, sin renunciar al modelo de programación de los Durable Objects. celld te da eso: cada objeto —al que llama celda— es su propia base SQLite, direccionada por nombre, replicada a un bucket que vos controlás. La contrapartida es que vos te hacés cargo de la infra: servidores, red privada, TLS e ingress.
El caso de uso natural, según sus autores, son cargas con muchísimo estado persistente de baja concurrencia: miles de agentes de IA, salas de chat, sesiones colaborativas o partidas de juego, donde cada entidad quiere su propia porción de estado consistente y aislado. El sharding es "por construcción": como cada celda es una base chica e independiente, desaparece la contención de una base compartida.
¿Cómo usa celld a S3 como capa de coordinación sin consenso?
celld reemplaza el consenso distribuido por una operación atómica del propio object storage: compare-and-swap (CAS) sobre un registro de propiedad. Cada celda tiene un único registro en el bucket. Si no existe, se crea de forma condicional; si existe, se adquiere con un CAS contra el valor previo. Como solo una escritura condicional puede ganar, es imposible que dos nodos posean la misma celda al mismo tiempo. No hay protocolo de membresía, ni detector de fallas, ni servicio de consenso.
Como lo resume la documentación oficial: "The bucket is the durable source of truth; nodes are replaceable" —el bucket es la fuente de verdad durable, los nodos son reemplazables. Sobre esa idea se apoyan tres mecanismos:
- Propiedad por CAS: el object-storage compare-and-swap garantiza que exactamente un nodo es dueño de una celda a la vez. Punto.
- Replicación continua con LTX: celld replica de forma continua la base SQLite de cada celda al bucket. Cuando una celda se mueve, o una celda inactiva se activa, su nuevo dueño restaura esa base desde el bucket y retoma la ejecución.
- Output gate: antes de devolver "éxito" a una escritura, celld re-verifica que el registro de propiedad siga apuntando al mismo nodo y epoch, apuntando a un RPO de cero. Es lo que evita que un dueño "zombi" confirme datos que ya perdió.
El costo de esta elegancia es latencia: la escritura durable mínima implica un round trip al bucket. Según el análisis técnico de XenoSpectrum, ese round trip intra-región ronda los 90 ms, "órdenes de magnitud más lento que una lectura local de SQLite". Las lecturas y escrituras dentro de una celda activa, en cambio, son locales y rapidísimas.
¿Qué necesita el bucket para que celld funcione?
El bucket tiene que soportar tres cosas, y no todos los servicios "compatibles con S3" las cumplen. Este es el requisito más subestimado antes de montar celld:
- Creación condicional: poder crear un objeto solo si no existe (para tomar propiedad de una celda nueva).
- Sobrescritura condicional (CAS): escribir solo si el valor actual coincide con el esperado (para transferir propiedad sin carreras).
- Consistencia read-after-write: leer inmediatamente el mismo valor que se acaba de escribir.
En la práctica funcionan los buckets con soporte de escrituras condicionales y precondiciones de generación —incluido Cloudflare R2 y Tigris—, mientras que varios servicios de object storage populares todavía no implementan escrituras condicionales y quedan afuera. Un ejemplo concreto es MinIO Community, que no cumple hoy con CAS (si venís de ese mundo, te va a interesar nuestra nota sobre MinIO archivado y qué usar ahora). Verificá esta capacidad puntual en tu proveedor antes de asumir compatibilidad: "habla S3" no alcanza.
¿Cómo se instala y despliega celld en tu servidor?
La instalación es un binario único y el despliegue apunta a tu bucket. El instalador descarga el binario celld:
curl -fsSL https://celld.dev/install.sh | shCada nodo embebe V8 y ejecuta bundles de Wrangler (acepta un subconjunto soportado de la configuración de Wrangler, incluyendo assets estáticos co-desplegados). Para publicar tu código y levantar un nodo:
celld deploy . --bucket s3://my-cells-bucket
celld --bucket s3://my-cells-bucket --listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 --advertise 10.0.0.12:8081Los flags separan el tráfico público (--listen) de la comunicación privada entre pares (--internal-listen / --advertise). Para el control de capacidad hay variables de entorno clave:
CELLD_MAX_RESIDENT_CELLS: límite duro de celdas residentes por nodo.CELLD_MAX_RSS_MB: umbral de memoria (por defecto, el 80% disponible) para empezar a descargar celdas inactivas.- Cadena de credenciales estándar: celld usa la cadena de credenciales habitual para autenticar contra el bucket.
Un detalle operativo importante: las credenciales del bucket equivalen a control sobre todo el cluster. Hay que scopear permisos con cuidado y se asume red privada entre nodos (WireGuard/Tailscale). Autenticación de usuarios, terminación TLS e ingress corren por tu cuenta.
¿Qué rendimiento y qué costo tiene celld?
Con la celda ya activa en un nodo, el rendimiento es local y muy bueno; el costo cae fuerte solo a alta utilización. Según los benchmarks publicados en celld.dev, un worker thread alcanza ~94.000 requests por segundo, la latencia de una request stateless ronda los 0,2 ms p50 y cada celda activa ocupa ~4 MB de memoria. El acceso a estado dentro de una celda activa reporta mediana de 1,1 ms y p99 de 7 ms.
| Métrica (fuente: celld.dev) | Valor reportado |
|---|---|
| Throughput por worker thread | ~94.000 req/s |
| Latencia request stateless | ~0,2 ms p50 |
| Estado en celda activa | 1,1 ms mediana / 7 ms p99 |
| Memoria por celda activa | ~4 MB |
| Round trip durable al bucket (intra-región) | ~90 ms (fuente: XenoSpectrum) |
En costos, celld.dev estima que 100 celdas residentes cuestan ~$49/mes contra ~$415/mes del mismo workload en Durable Objects de Cloudflare: una reducción cercana al 88%, porque las celdas dormidas tienden a costo casi cero (solo storage en el bucket). Pero hay letra chica que XenoSpectrum señala con razón: la propia documentación es inconsistente sobre la densidad (2.500 vs 1.000 celdas para un nodo de 8 GB), y la ventaja aparece solo con alta utilización. Para servicios esparsos, el modelo por uso más la hibernación de WebSockets del servicio administrado puede terminar saliendo más barato. Tomá el 88% como cota superior de marketing, no como garantía.
¿Cuáles son las limitaciones reales de celld hoy?
celld es alpha (v0.1.0) y lo dice sin vueltas: no es apto para escenarios multi-tenant con código adversario co-ubicado. Estas son las fricciones concretas que tenés que sopesar antes de apoyarte en él:
- Madurez alpha: v0.1.0 publicada el 5 de agosto de 2026. Sumó ~2.600 estrellas en GitHub en cuatro días, pero es código muy nuevo.
- Superficie de API incompleta: D1, Workflows y Queues están planeados; KV, R2 y Cache API quedan fuera de alcance. Faltan primitivas como
Response.redirect(),ReadableStream.from(),setIntervaly HTMLRewriter. - Stubs silenciosos: algunos módulos de Node.js y los sockets TCP existen como stubs que no procesan nada. Ojo con asumir que "funciona" sin probarlo.
- Latencia de durabilidad: el output gate y el round trip al bucket suman overhead a cada escritura durable (esos ~90 ms intra-región).
- Sin red global administrada: no hay CDN ni ingress global. Vos ponés la red privada, el TLS, el proxy y la planificación de capacidad.
- Dependencia de esbuild y de un object storage con CAS real (ver arriba).
¿Para quién es celld y cuándo NO conviene?
celld es para equipos que quieren decidir ellos mismos dónde viven sus datos y sus dominios de falla, corriendo muchas entidades persistentes de alta densidad —agentes de IA, salas de chat, colaboración en vivo— sobre servidores propios. Si ese es tu perfil y te sobra tolerancia a operar infra, encaja.
No conviene si necesitás ingress global administrado, aislamiento multi-tenant sólido contra código no confiable, o el menor overhead operativo posible. Tampoco si tu carga es esparsa y de bajo volumen: ahí el costo del servidor base no se amortiza. Y no lo pongas todavía como cimiento de un sistema crítico sin un plan de contingencia: es alpha.
Veredicto: ¿vale la pena celld?
celld es una de las piezas de infraestructura más interesantes de 2026: convierte un problema clásico de sistemas distribuidos —quién posee qué, sin split-brain— en una sola operación de compare-and-swap sobre object storage, y borra el control plane de la ecuación. La idea es limpia y el rendimiento en celda activa es real. Pero es v0.1.0: API incompleta, stubs silenciosos, latencia de durabilidad y advertencia explícita contra multi-tenant. Es un proyecto para prototipar, evaluar y seguir de cerca, no para poner debajo de producción crítica esta semana. Si el modelo de Durable Objects te cierra pero la dependencia de plataforma no, celld merece un lugar en tu radar y un cluster de pruebas.
Preguntas frecuentes
¿Qué es una "celda" en celld?
Una celda es una instancia de Durable Object: su propia base SQLite direccionada por nombre, replicada al bucket. Cada celda tiene un único dueño (un nodo) en cada momento, garantizado por compare-and-swap.
¿celld necesita un servicio de consenso o Raft?
No. Los nodos se coordinan solo a través del bucket compatible con S3, usando compare-and-swap para la propiedad. No hay control plane, protocolo de membresía ni servicio de consenso.
¿Sirve cualquier almacenamiento compatible con S3?
No. El bucket debe soportar creación condicional, sobrescritura condicional (CAS) y consistencia read-after-write. Varios servicios "compatibles con S3" no implementan escrituras condicionales y no funcionan; verificá esa capacidad puntual antes de elegir.
¿celld está listo para producción?
No todavía. La versión actual es la v0.1.0 (alpha), publicada el 5 de agosto de 2026, y no es segura para casos multi-tenant con código adversario co-ubicado. Es apta para evaluación y prototipos.
¿Con qué licencia se publica y quién lo mantiene?
Se publica bajo licencia Apache-2.0 y lo mantiene Deno (el equipo de Ryan Dahl). Está escrito en Rust sobre Tokio, con V8, SQLite y LTX en su stack.
Fuentes: repositorio oficial en GitHub (denoland/celld), sitio y documentación oficial celld.dev, análisis técnico de XenoSpectrum y cobertura de byteiota.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
