Deploy Watch: recuperación automática tras fallar las comprobaciones del despliegue
Una versión puede superar la comprobación inicial y fallar un minuto después. El proceso sigue ejecutándose, pero el endpoint de disponibilidad devuelve un error.
Deploy Watch añade una ventana corta de comprobaciones automáticas después de un despliegue compatible. Si los fallos se repiten, Upferry intenta iniciar y comprobar la imagen anterior antes de devolverle el tráfico.
v1: 200✓ Comprobar antes del cambiov2: 500× Tres fallos seguidosQué ocurre después de publicar
Upferry consulta el healthcheck configurado aproximadamente cada 15 segundos durante 10 minutos. Una respuesta correcta reinicia el contador. Tres fallos consecutivos inician un intento de recuperación.
La imagen anterior queda protegida frente a la limpieza habitual. Su proceso se detiene después del relevo normal. Durante la recuperación, Upferry inicia esa misma imagen sin recompilar, la comprueba, cambia el tráfico y confirma la ruta elegida.
Iniciar la imagen anterior lleva tiempo. La detección y el arranque pueden contribuir a la interrupción. Si falta la imagen, no hay recursos o falla la comprobación, el panel informa de una recuperación sin confirmar.
Cómo activarlo
Abre un servicio, entra en Settings y despliega Deploy Watch. El ajuste se comparte entre sus entornos; cada supervisión pertenece a un despliegue y entorno concretos.
- Configura un healthcheck que refleje la disponibilidad que quieres supervisar.
- Confirma los requisitos de la aplicación y activa Deploy Watch.
- Despliega una versión sana y después un cambio de solo código con la misma configuración de ejecución.
La primera versión admite una instancia HTTP sin volumen, cron ni comando previo al despliegue. Se necesita una versión anterior sana compatible. Activar el ajuste no protege retroactivamente una versión ya en ejecución.
La compatibilidad depende de la aplicación
El propietario debe confirmar que el arranque no ejecuta migraciones, consumidores de colas, temporizadores ni otras tareas con efectos secundarios. Dos versiones deben poder ejecutarse brevemente de forma segura. La base de datos actual, las escrituras aceptadas y los servicios relacionados deben ser compatibles con el código anterior.
Son requisitos confirmados por el propietario. Upferry no puede demostrarlos inspeccionando cualquier imagen Docker. Volver a una imagen no deshace cambios de esquema, acciones de clientes, pagos ni peticiones externas.
Deploy Watch recupera un servicio. No coordina una reversión de todo el proyecto.
Se mantienen los ajustes actuales
Deploy Watch no restaura secretos antiguos ni reduce la política de red. Un despliegue compatible conserva la misma configuración efectiva y variables que su versión sana de referencia.
Un despliegue nuevo, una acción manual de ciclo de vida o un cambio de configuración relevante cancela la supervisión anterior. Su estado sobrevive al reinicio del worker. Antes de confirmar la recuperación, Upferry verifica que el intento sigue perteneciendo al despliegue actual.
Qué comprueba
La petición se dirige a la versión elegida directamente y usa su entrada permitida existente cuando la red está restringida. Un endpoint que siempre devuelve 200 no detecta fallos en pagos, procesamiento de fotos o inicio de sesión.
No comprueba DNS público, TLS, fallos del proxy ni funciones fuera del endpoint elegido. La ventana termina y no sustituye a la supervisión continua. El historial muestra fallos, etapas y motivos de cancelación o error. Los canales de notificación configurados pueden comunicar el resultado.
Comparación con Railway
Railway documenta healthchecks antes de activar un despliegue y especifica que no continúan después. Sus acciones de despliegue incluyen una reversión manual.
En la documentación pública revisada el 27 de octubre de 2026 no encontramos este flujo integrado de supervisión y recuperación automática. Se puede construir una automatización parecida con monitorización, scripts y la API de Railway.