Despliegues

Un despliegue es un ciclo de build y puesta en marcha de un servicio en un entorno. Se crea con un push a la rama seguida, con skiffly up, al volver a desplegar desde el panel o con serviceInstanceDeployV2. El despliegue anterior sigue sirviendo tráfico hasta que el nuevo pasa su health check; después se elimina.

Ciclo de vida#

QUEUED → BUILDING → DEPLOYING → SUCCESS
                 ↘ FAILED        ↘ CRASHED
                                  ↘ SLEEPING (App Sleeping) ⇄ SUCCESS
        cualquiera → REMOVED (reemplazado, cancelado, servicio eliminado)

El enum completo es compatible con Railway; consulta la referencia de estados.

Disparadores#

• Push a la rama seguida de un repositorio conectado (o a la rama del PR en un entorno pr-*).
• skiffly up sube el directorio actual, lo construye y transmite los logs; --git construye en su lugar el HEAD ya enviado (push) del repositorio conectado, y --git --commit <sha> elige un commit.
• Volver a desplegar reconstruye y despliega otra vez el último commit con las variables y la configuración actuales (serviceInstanceRedeploy, skiffly redeploy, redeploy de MCP).
• Desplegar inicia un build nuevo (serviceInstanceDeployV2, deploy de MCP).
• Los cambios de variables vuelven a desplegar los servicios afectados unos cinco segundos después del último cambio (varias ediciones seguidas se convierten en un solo despliegue): el servicio dueño de la variable más todos los que la referencian con ${{servicio.VAR}}; una variable compartida redespliega todos los servicios del entorno. Pasa skipDeploys: true (skiffly variables set --skip-deploys, skipDeploys en MCP) para solo guardar. Los servicios que nunca se han desplegado no se tocan.
• Cambios de configuración: guardar ajustes de runtime (réplicas, CPU/memoria, ruta y tiempo de espera del health check, comando de inicio, cron, política de reinicio, builder, ruta del Dockerfile, comando de build, directorio raíz, rama) vuelve a desplegar un servicio en ejecución (serviceInstanceUpdate, skipDeploys: true para solo guardar). Las rutas de vigilancia se aplican en el siguiente push y App Sleeping se aplica en el sitio: ninguno de los dos redespliega.
• Revertir despliega la imagen guardada de un despliegue anterior; ver más abajo.

Logs#

Tres flujos por despliegue: build, runtime (deploy) y sistema (reinicios, OOM kills, eventos de programación).

skiffly logs                    # logs de runtime del último despliegue
skiffly logs -f                 # sigue en vivo (consulta cada 2 s)
skiffly logs --build            # salida del build
skiffly logs --system           # scheduler / reinicios / OOM
skiffly logs -n 500 --filter "error"
skiffly logs <deploymentId>

Los logs se conservan en un búfer circular con las últimas 5 000 líneas por despliegue; environmentLogs combina los búferes de los últimos despliegues del entorno. Las líneas más antiguas no se pueden recuperar, así que envía desde la app a tu propio servicio de logs todo lo que debas conservar.

Volver a desplegar, revertir, reiniciar, cancelar#

Reversión (rollback)#

Cada despliegue que llegó a ejecutarse conserva su imagen construida en el registry, junto con una instantánea de las variables y la configuración de runtime con la que corrió. Revertir a este en el menú del despliegue (o deploymentRollback(id)) crea un despliegue nuevo a partir de esa imagen e instantánea: sin clonar ni construir; la etapa Build se omite y la puesta en marcha tarda lo que tarden en arrancar los contenedores. Dominios, volúmenes, proxies TCP y límites de recursos son los de hoy; la imagen, las variables, el comando de inicio, el health check, las réplicas, el cron y la política de reinicio vienen de la instantánea. En los servicios de imagen se vuelve a desplegar la misma etiqueta. El despliegue aparece como Reversión a <commit> con el disparador rollback.

Deployment.canRollback es true cuando el despliegue llegó a ejecutarse (SUCCESS, REMOVED, CRASHED, SLEEPING) y su imagen sigue en el registry. Se conservan las imágenes de los 10 despliegues más recientes de un servicio que llegaron a ejecutarse, salvo los que llevan más de 14 días en REMOVED; las imágenes de builds fallidos, despliegues cancelados y más antiguos las borra un trabajo nocturno de retención (se rellena imageRemovedAt y la reversión se rechaza con un error claro: vuelve a desplegar el commit). La retención nunca toca la imagen que el servicio está ejecutando.

Puesta en marcha y tiempo de inactividad#

Un despliegue nuevo arranca junto al anterior y recibe tráfico cuando pasa el health check; después se detienen los contenedores antiguos. Con una ruta de health check esto ocurre sin tiempo de inactividad para los servicios HTTP. Los servicios con volumen son la excepción: el volumen solo puede montarlo un contenedor a la vez, así que el antiguo se detiene primero (unos segundos de inactividad para las bases de datos).

Una puesta en marcha que no llega a estar sana en 10 minutos se marca como FAILED y el despliegue anterior sigue corriendo. Los builds o puestas en marcha que dejan de reportar durante 20 minutos (un nodo desapareció) los marca como fallidos un watchdog.

Metadatos del despliegue#

Cada despliegue registra el SHA y el mensaje del commit, el disparador (webhook, manual, redeploy, rollback, variables, pr-preview, upload, billing), quién lo inició y un mensaje que explica esperas y fallos (ImagePullBackOff, OOMKilled, CrashLoopBackOff: <últimas líneas del log>, exceeded quota). skiffly deployment list y deployments(input: { serviceId, environmentId }) los devuelven.

Métricas#

CPU, memoria y tráfico saliente por servicio están disponibles en Proyecto → Observabilidad para la última hora, 6 horas, 24 horas o 7 días (serviceMetrics(environmentId, range: H1 | H6 | H24 | D7)). Las muestras en bruto (alrededor de una por minuto) se conservan 7 días; los agregados por hora se conservan 90 días y alimentan Espacio de trabajo → Uso, que muestra las mismas cifras agregadas al período de facturación.