Deploys

What happens between a push and a running container, how to read build and runtime logs, redeploy, roll back, cancel, and what each status means.

A deployment is one build-and-rollout of a service in an environment. It is created by a push to the tracked branch, by skiffly up, by a redeploy from the dashboard or by serviceInstanceDeployV2. The previous deployment keeps serving traffic until the new one passes its health check, then it is removed.

Lifecycle#

QUEUED → BUILDING → DEPLOYING → SUCCESS
                 ↘ FAILED        ↘ CRASHED
                                  ↘ SLEEPING (App Sleeping) ⇄ SUCCESS
        any → REMOVED (replaced, cancelled, service deleted)

Status	Meaning
`QUEUED`	waiting for a node; the only state that can be cancelled
`BUILDING`	Railpack/Dockerfile build in progress (or waiting for a build slot: two builds run at once per node)
`DEPLOYING`	image pushed, containers starting, health check not passed yet
`SUCCESS`	live and receiving traffic
`FAILED`	build failed, or the container never became healthy within 5 minutes, or the quota was exceeded
`CRASHED`	the container exited repeatedly after going live (three restarts in a row)
`SLEEPING`	scaled to zero by App Sleeping; the next request wakes it
`REMOVED`	replaced by a newer deployment, cancelled, or the service was deleted

The full enum matches Railway's; see the status reference.

Triggers#

Push to the tracked branch of a connected repository (or the PR branch in a pr-* environment).
skiffly up builds the pushed HEAD of the current branch and streams the logs; --commit <sha> picks a commit.
Redeploy re-runs the latest build with the current variables and settings (serviceInstanceRedeploy, skiffly redeploy, MCP redeploy).
Deploy starts a fresh build (serviceInstanceDeployV2, MCP deploy).
Settings changes that need a rebuild (source, builder, Dockerfile path) take effect on the next deploy; runtime settings (start command, health check, replicas, resources, cron) are applied by a redeploy, which the dashboard and CLI trigger for you.

Logs#

Three streams per deployment: build, runtime (deploy) and system (restarts, OOM kills, scheduling events).

skiffly logs                    # runtime logs of the latest deployment
skiffly logs -f                 # follow (polls every 2 s)
skiffly logs --build            # build output
skiffly logs --system           # scheduler / restarts / OOM
skiffly logs -n 500 --filter "error"
skiffly logs <deploymentId>

Logs are kept in a rolling buffer of the last 5 000 lines per deployment; environmentLogs merges the buffers of the environment's latest deployments. Older lines are not retrievable, so ship anything you must keep to your own log service from the app.

Redeploy, roll back, restart, cancel#

Action	What it does	CLI	GraphQL
Redeploy	new deployment from the latest build, current settings	`skiffly redeploy`	`serviceInstanceRedeploy(serviceId, environmentId)`
Roll back	new deployment from the image of an older `SUCCESS` deployment (no rebuild)	via dashboard	`deploymentRollback(id)` / `deploymentRedeploy(id)`
Restart	restart the containers in place, no new deployment	`skiffly restart`	`serviceRestart(serviceId, environmentId)`
Cancel	drop a `QUEUED` deployment	dashboard	`deploymentCancel(id)`
Remove	stop serving a deployment	dashboard	`deploymentRemove(id)`

Rolling back is a redeploy of the older deployment's image with today's variables and settings; if a variable change caused the problem, fix the variable and redeploy instead. Deployment.canRollback tells whether the image is still available.

Rollouts and downtime#

A new deployment starts alongside the old one and receives traffic once the health check passes; then the old containers are stopped. With a health check path this is zero-downtime for HTTP services. Services with a volume are the exception: the volume can be mounted by one container at a time, so the old one stops first (a few seconds of downtime for databases).

A rollout that has not become healthy within 10 minutes is marked FAILED and the previous deployment keeps running. Builds or rollouts that stop reporting for 20 minutes (a node went away) are failed by a watchdog.

Deployment metadata#

Each deployment records the commit SHA and message, the trigger (webhook, manual, redeploy, pr-preview, billing), who started it and a message explaining waits and failures (ImagePullBackOff, OOMKilled, CrashLoopBackOff: <last log lines>, exceeded quota). skiffly deployment list and deployments(input: { serviceId, environmentId }) return them.

Metrics#

CPU, memory and egress per service are available in Project → Observability for the last hour, 6 hours, 24 hours or 7 days (serviceMetrics(environmentId, range: H1 | H6 | H24 | D7)). Workspace → Usage shows the same aggregated into the billing period.