Despliegues

Qué pasa entre un push y un contenedor en ejecución, cómo leer los logs del build y de runtime, volver a desplegar, revertir, cancelar y qué significa cada estado.

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)

Estado	Significado
`QUEUED`	esperando un nodo; el único estado que se puede cancelar
`BUILDING`	build de Railpack/Dockerfile en curso (o esperando un slot de build: corren dos builds a la vez por nodo)
`DEPLOYING`	imagen subida, contenedores arrancando, health check todavía no superado
`SUCCESS`	en vivo y recibiendo tráfico
`FAILED`	el build falló, o el contenedor nunca llegó a estar sano en 5 minutos, o se excedió la cuota
`CRASHED`	el contenedor terminó repetidamente después de estar en vivo (tres reinicios seguidos)
`SLEEPING`	escalado a cero por App Sleeping; la siguiente solicitud lo despierta
`REMOVED`	reemplazado por un despliegue más nuevo, cancelado, o el servicio fue eliminado

El enum completo coincide con el de 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 construye el HEAD pusheado de la rama actual y transmite los logs; --commit <sha> elige un commit.
Volver a desplegar vuelve a ejecutar el último build 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 configuración que necesitan un nuevo build (origen, builder, ruta del Dockerfile) se aplican en el siguiente despliegue; la configuración de runtime (comando de inicio, health check, réplicas, recursos, cron) se aplica al volver a desplegar, algo que el panel y la CLI disparan por ti.

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#

Acción	Qué hace	CLI	GraphQL
Volver a desplegar	despliegue nuevo a partir del último build, con la configuración actual	`skiffly redeploy`	`serviceInstanceRedeploy(serviceId, environmentId)`
Revertir	despliegue nuevo a partir de la imagen de un despliegue `SUCCESS` anterior (sin nuevo build)	desde el panel	`deploymentRollback(id)` / `deploymentRedeploy(id)`
Reiniciar	reinicia los contenedores en el sitio, sin despliegue nuevo	`skiffly restart`	`serviceRestart(serviceId, environmentId)`
Cancelar	descarta un despliegue `QUEUED`	panel	`deploymentCancel(id)`
Eliminar	deja de servir un despliegue	panel	`deploymentRemove(id)`

Revertir es volver a desplegar la imagen del despliegue anterior con las variables y la configuración de hoy; si el problema lo causó un cambio en una variable, corrige la variable y vuelve a desplegar en su lugar. Deployment.canRollback indica si la imagen sigue disponible.

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, pr-preview, 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)). Espacio de trabajo → Uso muestra lo mismo agregado al período de facturación.

Buscar en la documentación