El problema
Producir un short educativo a mano cuesta entre dos y tres horas: buscar el tema, escribir el guion, generar el arte, grabar la voz, montar y publicar. A ese ritmo un canal de publicación diaria es inviable para una sola persona.
La arquitectura
El sistema está partido en tres piezas que se comunican por estado, no por llamadas directas:
- Orquestación (n8n) — diez workflows que mueven cada pieza de contenido por la máquina de estados.
- media-worker — microservicio de render: FFmpeg para el montaje y síntesis de voz para la narración.
- cc-browser — microservicio con Playwright que conduce un navegador para generar las imágenes.
El estado vive en Supabase y define el recorrido completo:
pendiente → produciendo → en_revision → en_aprobacion → aprobado → publicado
↘ rechazado
Cada transición es idempotente. Si el render falla a mitad, la pieza vuelve a pendiente y se
reintenta sin duplicar nada.
La decisión que más ahorró
El render corre en una instancia EC2 bajo demanda: se levanta cuando hay cola, monta, y se apaga. Un servidor encendido todo el día para trabajo que ocupa minutos es el error de costo más común en este tipo de sistema.
El paso humano que se dejó a propósito
Todo está automatizado salvo la aprobación, que llega por WhatsApp. Publicar contenido generado sin que nadie lo mire es la forma más rápida de arruinar un canal. El sistema pide un sí antes de publicar, y eso cuesta diez segundos.
Publicación
La subida a YouTube usa la Data API v3 con OAuth2 y videos.insert, gestionando la cuota diaria;
Instagram va por la Graph API como Reel. Ambas están documentadas en el repositorio.