Deployments and revisions

An app keeps two histories. The Deployments tab lists the versions of the app that were built and rolled out; the Revisions tab lists every change to its configuration. Reading them needs apps/read; going back to an earlier version or revision needs apps/write.

Deployment history

The Deployments tab lists the app's deployments, newest first, with their Phase, Message, Serving (whether the image runs a start script or serves a static site), Image, Source (the commit, linked to the repository) and Timestamp. The deployment that is serving now is marked Current. A slot's deployments are on the slot's page.

• For an app built from a repository, every build adds an entry, which goes from Building to Succeeded or Failed — see Deployment phases. The phase does not say whether the new instances became ready; the app's status does.
• For an app that runs a container image, an entry is added when the image changes.

Build logs

Choose an entry to open its Build Logs: live while the build runs, stored when it ends. Build logs are kept for 30 days. Reading them needs apps/readLogs.

Redeploy a version

To go back to a version of an app built from a repository, choose Redeploy this version on its entry. The action is not offered on the current deployment.

• When the version's image is still in the platform's registry, it is rolled out as it is, without a build.
• When the image is gone, the version's commit is built again; that takes several minutes, and the dependencies the build fetches may have changed since.

The app then stays on that version until the next push to its branch or a change of branch. Deploy builds the commit the app is on: after a rollout without a build, the commit it was on before; after a rebuild, the older commit again — see Deploy. A change to what goes into the image — runtime stack or version, port, startup project or build variables — rebuilds that version's commit with the change. On a slot's page the action redeploys the slot.

For an app that runs a container image the button is shown too, but it does not bring back that image. Set the image you want under Configuration → Deployment Source instead — see Change the container image.

Old images

The images built for an app are kept in the platform's registry. Its retention policy keeps by default at least the last two, everything built in the last 90 days, and always the ones that run, but today its clean-up removes no app images, so every image is kept — see Image retention.

Revisions

The Revisions tab lists every change to the app's specification, newest first, with who made it: saved configuration, and also each deploy, start, stop and restart, and each commit a push delivers. View changes shows how a revision differs from the one before it. The last 50 revisions are kept.

Roll back

1. On the Revisions tab, choose Roll back on the revision to go back to. The newest revision has no Roll back.
2. The row lists what the rollback changes — for example the compute plan, whether the app is rebuilt, slots added or removed, persistent storage, the branch or commit, hostname, port, HTTPS, scaling, environment variables and secret references.
3. Confirm with Roll back in the row, or choose Cancel.

The earlier configuration is applied like an edit and becomes the newest revision. Good to know:

• A rollback never starts or stops the app. A revision saved while the app was stopped does not bring back that stop; the scaling stays as it is now.
• The slots are restored as they were in the revision: slots added since are removed, and slots removed since are created again, getting back their disk if they had one.
• The rollback is refused if the app got a newer revision than the list shows — reload the tab — and if the revision holds values the platform withholds.