clundra
Documentation

Versions

Every deploy of every service is a version. This is the page you want when something just shipped and needs to un-ship.

A version is a build of the app's service

A version is one build of one service, listed under that service rather than merged into an app-wide timeline. Today an app has one service, so the two look the same; the distinction is kept because a version and a snapshot are different things — a version moves the service's code, a snapshot moves the whole app including its data.

Each version records what it was built from, whether it landed as a swap or a rebuild, and its outcome. A build that failed stays in the list with its log, because “what happened to my deploy” is the question that brought you here.

Restore puts a build back

Restoring a version puts that exact image back in front of traffic. No rebuild, so no chance of the same source producing a different result — it is the artefact you already ran, returned to service.

Not every version offers Restore, and that is not arbitrary. Only the previous completed deploy is guaranteed to still be held in the image store, so that is the one Restore is offered for. Older rows show what happened without offering to put back an image that may no longer exist — an offer that failed would be worse than no offer.

To go further back than that, deploy the commit you want from the list below, which rebuilds from source. To move the whole app — every service and its data together — see Snapshots.

The commit list is the whole branch

For a Git-sourced service you also get its branch's commits — not only the ones that were ever deployed. That is the point: somebody going back past a bad change has to be able to find the commit before it, whether or not it was ever built here. Commits you have deployed before are marked, so a known-good one is identifiable at a glance.

Deploying a commit from that list builds it and ships it like any other deploy, and it becomes a new version rather than overwriting history.

Five reasons a commit list is not there

These are kept distinct because only one of them is yours to fix, and rendering them all as an outage would send you to a status page over a setting:

ReasonWhat it means
GitHub is not connectedCommon, and not an error. A public repository deploys with no GitHub App installation at all, so the app works fully and simply cannot list commits. Connect GitHub in Integrations to get them.
The repository is not on GitHubCommits are read from GitHub. Deploys still work; there is no list.
GitHub could not be reachedAn outage, a rate limit, or no permission to see that repository. This one is temporary.
The service is image-sourcedCommits do not exist for a pulled image. Its deploys are still listed and still restorable — see Sources.
The branch genuinely has noneAn empty branch has nothing to show.

A missing commit list never means a missing deploy history. The two are read from different places, and the versions are always there.