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.
How a release happens
Each app runs on a single instance, and a release replaces the version on it. There is a short gap while the new version starts, and the deploy only counts as live once the app answers on its port. That ordering decides what a failure leaves behind:
Migrations run before the release, so a failed migration always leaves your old
version serving. A version that builds but then crashes on start, or listens on
the wrong port, does not: fix it or put the previous code back, and deploy.
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.
Undoing a deploy
There is no one-click rollback today. Deploys on our current hosting do not keep a build that can be released again. To undo a deploy, put the code back to the last version that worked and deploy it: agit revert and push, your agent
restoring the previous version, or an upload of the last working folder.
Undoing code does not undo a database migration. Undo a bad
deploy walks through both.
There is no deployment configuration file. Build and start commands come from
analysis of your code, and the release behaviour above is not configurable.
Compute
The single-instance limit and what follows from it.