Cómo ejecutar Cloudflare Durable Objects en tus propios servidores usando celld

Ryan Dahl y el equipo de Deno han liberado silenciosamente el proyecto celld como código abierto. Si alguna vez has envidiado a los usuarios de Cloudflare por su concepto de Durable Objects pero no querías lidiar con el vendor lock-in, esto podría interesarte.

celld es un daemon runtime de Rust que puede ejecutar bundles de Cloudflare Workers e instancias aisladas de Durable Objects en tu propio hardware. Sin Etcd, sin Raft, y sin servicios pesados de coordinación.

El núcleo del concepto

Los backends tradicionales típicamente se dividen en microservicios sin estado y una única base de datos relacional grande. A medida que aumenta la carga, la base de datos inevitablemente se convierte en el principal cuello de botella.

Cloudflare propuso un enfoque diferente. Cada entidad activa de la aplicación (por ejemplo, una sala de chat, un carrito de compras o una sesión de documento) obtiene su propio isolate de V8 y una base de datos SQLite personal. El objeto se activa cuando llega una solicitud, mantiene el estado en memoria y un archivo SQLite local, y simplemente se queda dormido cuando está inactivo.

El problema principal era la naturaleza cerrada del ecosistema: ejecutar dicha configuración fuera de la infraestructura de Cloudflare era prácticamente imposible hasta ahora.

Cómo funciona celld internamente

Los desarrolladores de celld optaron por una simplificación radical. La arquitectura del nodo consiste en cuatro componentes:

1. V8 embebido para ejecutar código JavaScript y TypeScript de los bundles de Wrangler.
2. SQLite local para el archivo de base de datos separado de cada objeto.
3. Almacenamiento compatible con S3 (AWS S3, MinIO, Cloudflare R2) como única fuente de verdad.
4. Transporte entre servidores con firma HMAC para el intercambio de datos entre nodos.

La solución más interesante aquí es el abandono de los protocolos clásicos de consenso. Los nodos del clúster no necesitan elegir un líder ni ejecutar Consul.

En su lugar, los servidores se comunican con S3 a través de una operación atómica de Compare-And-Swap (CAS). Cuando un nodo quiere tomar posesión de un objeto, escribe un archivo de propiedad en el bucket de S3. Quien consiga actualizar el registro mediante CAS primero maneja el tráfico. Si un nodo falla, el tiempo de espera de escritura expira, y un servidor vecino recoge el objeto, descarga su base de datos SQLite actualizada del bucket, y continúa trabajando.

Lanzamiento y despliegue

Las construcciones estándar de Wrangler funcionan para compilar el proyecto, pero necesitarás un servidor con 5 y el binario en sí 6.

La instalación se realiza con un único comando:

0

El flujo de trabajo se divide en dos pasos. Primero, sube la construcción del worker al bucket:

1

Luego inicia el daemon en el servidor:

2

Cada nodo del clúster lee el manifiesto 7 del bucket. Si necesitas levantar un servidor adicional, lanzas otro proceso con el mismo bucket y especificas su dirección de red en 8.

En cuanto a seguridad: el tráfico entre servidores de celld no cifra TLS de forma predeterminada. Los autores recomiendan colocar los puertos internos de los nodos detrás de una red overlay segura como WireGuard o Tailscale. Todas las solicitudes entre pares se firman automáticamente con una clave HMAC 9 que el primer nodo crea automáticamente en el bucket.

Diagnóstico y gestión de carga

Para monitorear el clúster, existe la utilidad 10. Sondea a los vecinos y muestra las métricas actuales:

3

El comando mostrará el consumo de CPU, la memoria RSS, el número de conexiones WebSocket activas y la cantidad de objetos activos en cada nodo.

Si un servidor comienza a sobrecargarse, celld tiene un mecanismo de descarga de presión para objetos activos. Los límites se configuran mediante variables de entorno:

4

Cuando se supera el umbral, celld guarda los objetos inactivos en S3, libera la propiedad y deja de aceptar nuevas entidades hasta que la carga baje al valor de 11. Los objetos con solicitudes frecuentes o conexiones WebSocket abiertas no se ven afectados.

Un enfoque inusual para contribuir

Si vas al repositorio 12 con la intención de abrir un Pull Request, encontrarás el botón deshabilitado. Los forks están permitidos, pero los PRs en GitHub están completamente deshabilitados.

Ryan Dahl lo explica como una lucha contra el spam de los agentes de IA: revisar enormes pull requests generadas automáticamente sin contexto consume demasiado tiempo de los mantenedores. Aquellos que quieran enviar un parche deben hacer 13 y enviar el archivo por correo electrónico a la dirección personal 14.

Quién debería echarle un vistazo a este proyecto

El proyecto está en desarrollo activo, con las especificaciones del protocolo almacenadas directamente en el código del crate de Rust 15. Es demasiado pronto para integrarlo en producción crítica, pero definitivamente vale la pena experimentar.

La herramienta será útil en los siguientes casos:

1. Desarrolladores de servicios multijugador, chats y CRMs personalizados.
2. Equipos que planean alejarse del vendor lock-in de Cloudflare sin reescribir código.
3. Aficionados a la arquitectura con una base de datos separada por cliente-usuario.
4. Ingenieros que aprenden sobre sistemas distribuidos sin Raft ni Etcd.