Despliegue blue-green en un VPS: actualizar sin cortar el servicio

Publicado el 2026-11-14 por frfrand

Cómo preparar dos versiones, comprobar salud, cambiar Nginx y volver atrás con seguridad.

El problema: una actualización no debería dejar la aplicación inaccesible

Reiniciar una aplicación directamente sobre la única instancia activa crea una ventana de riesgo: si falla el arranque, una dependencia o una migración, todos los usuarios lo notan. El despliegue blue-green reduce ese riesgo manteniendo dos versiones ejecutables: blue sirve las peticiones actuales y green recibe el nuevo código. No equivale por sí solo a alta disponibilidad: si el VPS falla, las dos versiones caen.

Arquitectura mínima en un único VPS

Organiza cada versión en un contenedor o servicio independiente, por ejemplo en los puertos internos 8101 y 8102. Nginx escucha HTTPS y envía tráfico solo al servicio activo. Mantén separados los directorios de releases, los logs y los artefactos; comparte únicamente servicios que realmente deban ser comunes, como una base de datos externa o un almacenamiento persistente diseñado para acceso concurrente.

Un flujo razonable es GitHub → build inmutable → green → validación → cambio de proxy → monitorización. En GitHub Actions, el proceso de CI debe ejecutar tests y construir el artefacto antes de entregarlo al VPS. No construyas sobre el directorio que está atendiendo a usuarios.

Preparar el candidato sin tocar producción

1. Descarga el commit exacto y registra su identificador. 2. Arranca green con su propio puerto, variables adecuadas y límites de recursos. 3. Ejecuta comprobaciones de conexión a base de datos, endpoint de salud, autenticación y un flujo de negocio crítico. 4. Confirma que green puede funcionar con el esquema de base de datos que sigue utilizando blue.

El endpoint /health no debe devolver 200 simplemente porque el proceso esté vivo. Distingue liveness de readiness: una aplicación puede funcionar como proceso y no estar preparada para recibir peticiones.

Cambiar tráfico mediante Nginx

Puedes mantener un archivo de upstream controlado por el proceso de despliegue y cambiar el servidor activo. Después ejecuta nginx -t antes de recargar Nginx mediante systemctl reload nginx. Prueba primero esta operación en un entorno no productivo: errores de sintaxis o de permisos pueden dejar el proxy mal configurado.

Las conexiones abiertas y los trabajos que se estaban ejecutando requieren atención especial. WebSockets, peticiones largas, sesiones locales y colas de trabajo necesitan cierre ordenado. Mantén blue disponible durante un intervalo de observación suficiente y revisa latencia, errores 5xx, logs y métricas de negocio.

El punto más peligroso: las migraciones de datos

Cambiar Nginx hacia blue no deshace una migración destructiva. Diseña primero cambios de esquema compatibles hacia delante y atrás: agrega columnas antes de exigirlas, despliega lectores tolerantes y elimina campos antiguos solo en un despliegue posterior. Haz copias verificadas y documenta cuáles serían las consecuencias de revertir código y no datos.

Rollback probado, no improvisado

El procedimiento de vuelta debe estar escrito y ensayado: identificar el release anterior, validar que sigue sano, restablecer el upstream, comprobar Nginx y confirmar las operaciones críticas. Si el problema afecta a escrituras compartidas, quizá sea necesario detener cambios y analizar consistencia antes de restaurar información.

Cuándo conviene

Blue-green funciona bien para APIs, paneles y SaaS con tráfico constante cuando caben dos instancias en la memoria disponible. Si el VPS no soporta ese doble consumo, considera mantenimiento planificado o un segundo servidor. Para profundizar en la publicación de aplicaciones consulta despliegue de Next.js en VPS y Docker Compose en producción. La administración de VPS de ArduMaker puede facilitar la operación de la infraestructura, sin sustituir las pruebas de tu aplicación.

Preguntas frecuentes

### ¿Es cero downtime garantizado? No. Reduce interrupciones por cambios de versión, pero no elimina problemas de infraestructura o compatibilidad. ### ¿Necesito dos VPS? No necesariamente; dos servicios aislados pueden residir en uno, si hay recursos. ### ¿Qué hago con los workers? Actualízalos con una estrategia propia, evitando procesar el mismo trabajo dos veces.