The deployment lifecycle
Triggering a deployment for a service container doesn’t make it live in one step. It moves through two distinct stages — build, then deploy — and each can succeed or fail independently.
Build and deploy are separate stages
Section titled “Build and deploy are separate stages”Build takes the commit you’ve selected and turns it into a container image: your application, packaged and ready to run.
Deploy takes that image and rolls it out — creating or updating the running service with the image, its configuration, and its resource settings.
Splitting the two matters because they fail for different reasons. A build fails because of the code itself — a broken Dockerfile, a missing dependency. A deploy fails because of the environment — invalid configuration, insufficient resources. Keeping them separate makes it clear which one to look at, and lets a deployment stop cleanly before touching the running service if the build never produced anything to deploy.
Deployment status
Section titled “Deployment status”A deployment’s overall status reflects where it is in that sequence:
| Status | Meaning |
|---|---|
| Pending | Queued, not started yet |
| Building | The build stage is running |
| Deploying | The build succeeded; the deploy stage is running |
| Succeeded | The new version is live |
| Failed | Either stage failed |
| Cancelled | Stopped before completion |
Each stage also has its own status — pending, running, success, or failed — visible independently so you can tell, for a failed deployment, whether it never built or built but failed to deploy.
What “live” means
Section titled “What “live” means”There’s no separate “live” record to check — the current state of a service is always read directly from what’s actually running, not from a stored flag. In practice, “live” means: the image produced by the most recent successful deployment, running with whatever replica count and resources are currently in effect.
Scaling and hibernation shape what’s running, not the deployment itself
Section titled “Scaling and hibernation shape what’s running, not the deployment itself”Two settings continue to affect a service after it’s deployed, independently of any new deployment:
- Autoscaling adjusts the number of running replicas based on CPU usage, between a minimum and maximum you set.
- Hibernation scales a service to zero replicas on a schedule — useful for environments that don’t need to run around the clock.
Both act on the currently deployed version. They change how many copies of your service are running and when, not what code they’re running — that only changes with a new deployment.