Skip to main content
Every deploy is recorded against the application: what it built, how it ended, and the image it produced. That last part is what makes rollback instant.

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.
Rollback restores your application code only. It does not reverse database migrations.If the release you are rolling back from changed your schema, check that the older code can still run against it. The safest pattern is additive migrations that both versions tolerate.

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.
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.