How a deployment works
This is the part of the model that pays off most over time. Four concepts, deliberately kept separate:
| Concept | Definition | Does it change? |
|---|---|---|
| Build | The process that turns code into an artifact | — |
| Artifact | The built image, identified by a unique fingerprint | No |
| Version | The complete configuration of a deployment: artifact, variables, resources, address | No |
| Active version | The version receiving traffic | It is a pointer |
Everything you experience as reliability follows from this.
Promoting reuses the same artifact
When the same artifact is deployed to another environment, it is exactly the same binary, bit for bit. There is no rebuild. "It worked in one environment and broke in the other" loses its most common cause.
No version is overwritten
Every change — new code, a changed variable, an adjusted resource — creates a new version. The previous one stays whole in the history.
Restoring is a pointer switch
Restoring a previous version does not undo an update and rebuilds nothing: the target version is still complete, with an artifact already approved, and what happens is a change in which version receives traffic. That is why the product can promise that the version that worked comes back the same.
The five states you see
Internally, a deployment goes through many precise states. In the interface you see five:
Preparing → Building → Deploying → Verifying → Online
And three possible outcomes besides Online: Could not deploy, Cancelled, and Previous version restored.
The full table, with what to do in each, is in Deployment states.
Verifying is not decoration
The Verifying state exists because "the platform accepted the deployment" and "the application is answering" are different things. Traffic is only switched after the new version becomes ready — and ready, for the platform, means accepting TCP connections on the service's port. It is not an HTTP check: the platform does not know which path your application answers.
If the application does not become ready, the deployment fails with the reason, and nothing is switched. See Deployment states.
Each deployment records how far it was confirmed, on a four-step ladder:
Image checked → Configuration applied → Application answering → Address confirmed
The last step only comes from real traffic: a request from the internet that the application answered. A fresh deployment stays at 3 of 4 until that first request.
When a deployment was accepted but no process ever came to exist, the response says so rather than leaving it implied. It is the same standard that makes a request for application logs, before any application is running, answer "there is no run yet" instead of returning an empty list — empty would mean "it ran and wrote nothing", and confusing the two sends you looking in the wrong place.
Cancelling has a window
A deployment can be cancelled while it is preparing or building. Once the artifact has been pushed, cancelling stops being an option: the option becomes restoring the previous version.
When it fails
A failed deployment does not leave the service without an active version: the previous one keeps serving, intact.
The platform collects the evidence of that failure — the relevant build output, the moment of failure, the events, the version change — and correlates it all into a single object, with secrets already protected. That evidence feeds the screen, the diagnosis, and the agent helping you investigate, so all three see the same truth.
What you read looks like:
The application started but did not answer. Make the application listen on
0.0.0.0, on the port from thePORTvariable.
Not an invitation to go hunting through a dashboard.
Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.