Cómo construimos el flujo de despliegue de Tradevo

Hace dos años desplegábamos un site de cliente así: portátil abierto, ssh, git pull, pnpm install, pnpm build, pm2 restart, a veces un nginx reload manual, cruzar los dedos. Por site, alrededor de media tarde. Con veinte sites eso dejó de ser económico.

Tradevo.nl es nuestra solución interna: sin Kubernetes, sin Docker Swarm, sin orquestador sofisticado. Sí un conjunto plano de scripts TypeScript, un registro de puertos en JSON, plantillas de systemd y un panel web ligero. Cada pieza existe porque nos topamos con el problema.

El registro de puertos es el corazón. Cada site de cliente recibe un puerto entre 3000 y 3099. Se acabaron las colisiones. Un script de Node lee el registro, genera un archivo de servicio systemd por cliente y su correspondiente vhost de nginx. Despliegue = tar + scp + extract + install + build + systemctl restart. Cinco minutos.

El puzzle más difícil fue la automatización de Let's Encrypt. Los certificados que caducan sin aviso son el escenario de fallo más banal en un VPS. Escribimos un cron que renueva 7 días antes de la expiración, hace fallback a un webroot-challenge si DNS-01 no funciona, y envía un Slack-webhook ante códigos de salida inesperados.

Un extra: la API de Cloudflare. Automatizamos la creación del registro A en clientes nuevos, lo dejamos inicialmente en grey-cloud para la emisión del certificado, y lo pasamos a orange-cloud tras la validación. Eso ahorra cinco minutos por site y evita un clásico error de Let's Encrypt contra el proxy de Cloudflare que es fácil de cometer.

Liberar Tradevo como open source está en discusión. La base de código actual está muy acoplada a nuestra configuración de VPS (Ubuntu 24 + nginx + systemd), pero una variante abstraída parece útil para estudios con 10-30 sites de clientes. Si te interesa: [email protected].