Deadbolt
Infraestructura de trabajo duradera con workers autoadministrables. Arquitectura basada en Go control plane, ejecución en Node.js y PostgreSQL para persistencia.
Ficha actualizada 23 sept 2026, 7:03 · upstream 23 sept 2026, 6:58 · release sin release detectada
Qué es Deadbolt
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Deadbolt es una infraestructura robusta para ejecutar flujos de trabajo multi-paso de forma fiable. Permite a los desarrolladores definir tareas y dependencias, mientras el runtime persigue el progreso, coordina los workers y proporciona visibilidad sobre la recuperación. El enfoque se centra en resolver un problema práctico: cuando un flujo se detiene, ¿puedes explicar qué sucedió y decidir con seguridad lo siguiente? Se construye alrededor de una arquitectura donde el control plane (en Go) decide qué puede ejecutarse y registra el estado, mientras los workers (autoadministrables en Node.js) realizan la lógica del negocio. El sistema mantiene un registro inmutable de intentos, eventos y resultados, permitiendo reconstrucción precisa incluso cuando las notificaciones fallan o se pierden.
- Procesamiento de documentos con pipelines multi-paso donde el estado debe persistir entre etapas
- Flujos de trabajo de IA que requieren persistencia de contexto y recuperación ante fallos
- Automatización empresarial con dependencias complejas y necesidad de rollback seguro
- Pipeline de investigación científica o análisis de datos con múltiples pasos intermedios
- Sistemas de notificación en tiempo real donde la durabilidad del estado es crítica
- Arquitectura dual: control plane en Go (declarativo y persistente) + workers autoadministrables en Node.js (lógica de negocio)
- PostgreSQL como fuente única de verdad para el estado, con outbox para eventos transaccionales
- Reconocimiento de tenencia temporal: un worker puede recibir tareas de un dueño anterior caducado sin sobrescribir resultados
- Inmutabilidad de despliegues: cada nuevo bundle afecta solo a nuevos intentos, manteniendo la identidad del run existente
- API y dashboard para inspeccionar runs, eventos y recuperación en tiempo real
- No incluye SDK o CLI instalable; el uso requiere compilación local de TypeScript y configuración manual
- El control plane es modular pero no tiene un framework de despliegue completo (Kubernetes, multi-region) por defecto
- La persistencia en PostgreSQL puede ser lenta para flujos con gran volumen de intentos
- No incluye gestión automática de dependencias entre workers ni reintentos escalonados
- El sistema asume que los inputs/outputs son acoplables; no soporta workflows totalmente asíncronos sin sincronización
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Instalación: despliega el control plane con Docker Compose, inicia los workers en modo de prueba y registra un bundle inmutable. Para producción, despliega el control plane en Kubernetes o en la nube (AWS/Azure/GCP) con entornos separados para runs activos y bundles históricos. Usa NATS JetStream para notificaciones internas y S3-compatible para outputs grandes. Monitorea con Prometheus + Tempo + Loki. Actualiza bundles mediante GitHub Actions o scripts de CI/CD. Los workers deben ejecutarse en instancias independientes con acceso a la base de datos y NATS, separados del control plane por seguridad.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.