Deployments
A deployment is a single attempt to build and ship a commit of an app.
A deployment is a single attempt to build and ship a commit of an app.
This page is a work in progress.
Status lifecycle
| Status | Meaning |
|---|---|
pending | Queued, waiting for the builder to pick it up |
building | Build Job is running (git-clone → image-build → push) |
deploying | Image pushed, controller applying K8s manifests |
live | Deployment is running and passing health checks |
failed | Build or deploy failed — see logs for details |
stopped | App was manually stopped — K8s resources have been torn down |
Runtime health
Separate from deployment status, the app page also shows an Unhealthy indicator when the last deploy succeeded but the running pod is currently misbehaving. This can appear at any time after a deploy — for example if the app crashes hours after going live — and clears automatically once the pod recovers.
| Reason | Meaning |
|---|---|
CrashLoopBackOff | The app keeps crashing right after it starts, so Kubernetes is repeatedly restarting it with a growing delay between attempts |
ImagePullBackOff | Kubernetes couldn't download the container image and is waiting before trying again |
ErrImagePull | Kubernetes couldn't download the container image — it may not exist, or access may be denied |
{reason} (exit {code}) | The app's process exited unexpectedly with the given exit code (e.g. OOMKilled (exit 137) means it ran out of memory) |
restarting repeatedly | The app has restarted several times in the last few minutes, which usually means it's failing shortly after startup |
readiness probe failing | The app is running, but it isn't passing the health checks it needs to pass before it can receive traffic |
no running pods | There's no running instance of this app right now |
No indicator is shown while a deployment has no pods yet (e.g. just after triggering) or while the app is healthy.
Triggering a deployment
Deployments can be triggered:
- Manually from the app page in the UI
- Via webhook from GitHub, GitLab, or Gitea on push
Deploy actions
The app page exposes up to three deploy actions depending on the app's current state:
Redeploy
Re-applies the Kubernetes manifests using the same image from the current deployment. The controller reads all settings (port, environment variables, secrets) fresh from the database — so any changes you saved since the last deploy are picked up without requiring a rebuild.
Use Redeploy when:
- You changed an environment variable, secret, or port and want to apply it to the running app
- You want to restart the app without pulling a new image
Rebuild (git apps)
Creates a new deployment record and triggers a full build: git clone at the latest commit on the configured branch → Railpack build → image push → deploy.
Use Rebuild when:
- You have pushed new code and want to pick it up
Deploy new (image apps)
Creates a new deployment record and re-resolves imageUrl:imageTag at deploy time. If the tag (e.g. latest) has been updated in your registry since the last deploy, the new image version is used.
Use Deploy new when:
- You have pushed a new image to your registry and want to pull it
Viewing logs
Two log views are available from the app page:
- Deploy logs — output from the build pipeline and Kubernetes rollout, scoped to a specific deployment. Available for all apps regardless of source type.
- App logs — live stdout/stderr streamed directly from the running container over SSE. Only available while the app is
live. Logs are not stored — open the panel to start a live stream.