vivijure-control-plane
Control plane alojado para Vivijure Studio construido como único Cloudflare Worker en Next.js/Node.js. Gestiona tenencia, onboarding y aprovisionamiento sin modificar el software del estudio publicado.
Ficha actualizada 25 sept 2026, 22:36 · upstream 25 sept 2026, 22:07 · release v1.28.1
Qué es vivijure-control-plane
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Este repositorio implementa un control plane alojado para Vivijure Studio, actuando como puerta de entrada centralizada para la gestión de cuentas, autenticación y aprovisionamiento de estudios compartidos. El sistema garantiza que la versión alojada nunca deriva de la auto-alojada mediante el uso de artefactos publicados inmutables y hashes SHA256 en los manifiestos.
La arquitectura se basa en un único Cloudflare Worker que gestiona todo el ciclo de vida del usuario: desde el registro con autenticación mágica o OAuth, pasando por la aceptación de políticas de uso aceptable (AUP) versionadas, hasta el aprovisionamiento automático de bases de datos D1, almacenamiento R2 y workers de renderizado. El control plane no almacena datos de filmación, solo metadatos de tenencia, manteniendo una separación estricta entre la lógica de negocio del estudio y la gestión de usuarios.
La seguridad se refuerza mediante un esquema bifásico de claves RunPod: una clave A efímera para crear endpoints GPU y una clave B almacenada en el estudio para su ejecución. Esta estrategia minimiza la superficie de ataque, ya que la clave poderosa nunca persiste en los servidores del control plane. Además, las sesiones utilizan cookies __Host- HttpOnly y Secure para proteger la integridad entre subdominios vecinos.
- Gestión centralizada de cuentas y autenticación multi-proveedor (Magic Link, Google, GitHub) para plataformas SaaS compartidas.
- Aprovisionamiento automático de estudios completos (D1, R2, Workers) a partir de artefactos publicados sin intervención manual.
- Implementación estricta de políticas de uso aceptable (AUP) versionadas que bloquean el acceso hasta la aceptación explícita del usuario.
- Administración de suscripciones y suspensiones de tenencias mediante tokens bearer protegidos, sin afectar la funcionalidad del estudio subyacente.
- Arquitectura desacoplada donde el control plane alojado no almacena datos de filmación, solo metadatos de tenencia en D1.
- Uso de claves RunPod bifásicas (Key A efímera y Key B almacenada) para minimizar riesgos de seguridad en la creación de endpoints GPU.
- Implementación estricta de cookies __Host- para sesiones seguras entre subdominios vecinos, previniendo ataques CSRF o hijacking.
- Validación de integridad mediante hashes SHA256 en los manifiestos de paquetes del estudio, asegurando que no haya derivas entre versiones.
- Dependencia crítica de la infraestructura RunPod; fallos en el lado del cliente requieren reintroducción manual de claves (error 409).
- Ausencia de edición comunitaria o características pagas diferenciadas, manteniendo una funcionalidad idéntica a la versión auto-alojada.
- Configuración inicial compleja que requiere variables de entorno y secretos gestionados externamente en wrangler.toml.
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.
Utilizar las variables de entorno declaradas en wrangler.toml.example para evitar hardcodeo. Apuntar AUP_URL a un ref inmutable, nunca a una rama móvil. Validar integridad del paquete antes de subirlo al namespace de dispatch.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
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.