Skip to content

Admin guideApps and the estate

Deployments, rollback and retention

What a build leaves behind, how rollback works, and how many deployments each app keeps.

View as Markdown

Every successful deploy is kept as a deployment. One is serving; the others are what an owner can roll back to.

Setting Where Effect
Most deployments an app may keep (max_versions_per_app) Admin → Settings Caps every app, whatever its owner asks. 0 means no limit.
Delete old deployments automatically, Deployments to keep The app’s settings The owner’s choice, within your cap

Only successful deployments count toward either number, and the serving one is one of them. A failed build’s files are removed when it fails; its entry and build log stay, so a run of failed deploys never pushes a rollback target off the disk.

Owners see the policy that applies on the app’s Deployments tab.

An owner can delete one deployment, or every one that is not current. Deleting an app removes its deployments, workload and storage attachments — not the data in a store.

The owner picks a deployment and makes it current; the workload restarts onto it with no rebuild. toft rollback does the same and names the deployment first.

A restart is not a deploy. The dependency policy, source policy and language version are judged as they were for that deployment, so an app does not fail to return because an advisory landed overnight.

A start replaces the deployment’s directory from the stored artifact. Editing files in a running app’s directory does not survive a restart.

Deployments live under APPS_DIR by default. If the disk does not survive replacement, or you run isolated mode, configure an artifact store.

Deleting an app removes its directories under APPS_DIR and JOB_RUN_DIR. Every five minutes Toft also removes any directory there that no app owns and that has been untouched for an hour — left by a crash, or by a build still running when its app was deleted. Admin → System checks shows the last one it removed under Release disk.