Deployment history
The Deployments tab lists releases newest first. Each row carries its status, when it ran, and (when the deploy came from GitHub) the commit it built.Statuses
A failed deploy carries its reason, and where the failure happened during the
build, the build log with it. Where the container built but would not start,
the failure shows what the container printed on its way out.
Rolling back
Any earlier deployment that produced an image can be restored. Antideploy points the service back at that image; there is no rebuild, so it takes about as long as a release rather than a full deploy.1
Open Deployments
Go to the Deployments section of your app.
2
Choose the release
Find the deployment you want back. Rows that can be restored show a Roll
back button; the currently live one does not.
3
Roll back
Click it. The service is re-pointed at that deployment’s image and a new
entry is recorded.
Zero-downtime releases
The running version keeps serving until the new one has been built and has passed its health check. If the new version fails to start, the old one is left in place and the deploy is marked failed; you do not get a window where neither is up.Because each app runs on at most one instance, there is no percentage-based
rollout, no canary, and no way to have two versions serving at once. The
cutover is a switch, not a gradual shift.
Compute
The single-instance limit and what follows from it.