SyncBridge
SyncBridge es un panel de control autoalojado para gestionar tareas cron, watchers de archivos y sincronizaciones rsync/rclone. Ejecuta comandos nativos del host mediante nsenter en contenedores endurecidos, con logs en vivo, protección contra solapamientos y gestión de identidad explícita.
Ficha actualizada 25 sept 2026, 16:01 · upstream 25 sept 2026, 15:41 · release sin release detectada
Qué es SyncBridge
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
SyncBridge es una herramienta de automatización diseñada para orquestar tareas en el sistema anfitrión desde un plano de control autoalojado. A diferencia de las soluciones que ejecutan todo dentro del contenedor, SyncBridge utiliza `nsenter` para ejecutar comandos, scripts y sincronizaciones directamente en los namespaces del host (mount, UTS, IPC, network, PID), manteniendo el controlador en un único contenedor Docker endurecido. Esto permite una ejecución nativa sin necesidad de montar sockets de Docker ni sistemas de archivos completos del host dentro del contenedor.
- Gestión centralizada de tareas cron y scripts en múltiples servidores Linux desde una interfaz web única.
- Sincronización de archivos mediante rsync o rclone con watchers de sistema de archivos y protección contra solapamientos.
- Auditoría y gestión de inventario de crons, systemd e inotify del host, con capacidad de restaurar definiciones eliminadas desde el contenedor.
- Ejecución segura de scripts heredados en entornos autoalojados sin necesidad de reescribirlos para correr dentro de Docker.
- Ejecución nativa del host mediante `nsenter` con namespaces compartidos, evitando la exposición del socket de Docker.
- Modelo de seguridad explícito: UID/GID fijos o propiedad del script, sin caídas silenciosas a root.
- Persistencia en el host: crons y systemd units que sobreviven a fallos del controlador, con inventario importado desde el sistema.
- API v1 revision-aware con eventos SSE para monitoreo en tiempo real de ejecuciones.
- Imágenes multi-arquitectura (amd64/arm64) con validación de CI antes del despliegue.
- Protección contra solapamientos y gestión de grupos de procesos para detener tareas de forma segura.
- Requiere `pid: host`, `CAP_SYS_ADMIN` y `CAP_SYS_PTRACE`, lo que implica un modelo de confianza explícito con el host.
- No incluye herramientas como rsync, rclone o shells en la imagen; deben estar disponibles en el sistema anfitrión.
- En entornos con AppArmor activo, es necesario configurar `apparmor=unconfined` para permitir el acceso a namespaces del host.
- La interfaz web y API no están diseñadas para entornos de red pública sin proxy inverso o VPN.
- Dependencia de Docker Engine o implementación compatible con Compose para la gestión del contenedor.
Capturas del proyecto
Imágenes reales detectadas en la documentación del repositorio.
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.
Despliegue mediante `docker compose` con archivo `compose.yaml` y variables en `.env`. Requiere host Linux con namespaces PID compartidos, AppArmor desactivado o configurado como `unconfined`, y acceso a `/proc/1/root`. Montar solo el directorio `/config` como escribible. Proteger la instancia detrás de un proxy inverso autenticado y TLS. No exponer directamente a redes no confiables.
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.