Roll back a bad deploy on Levelrail

Before you start

• A Levelrail control plane with the CLI signed in.
• An app with at least one earlier successful deploy. The examples call it web.

When you need a rollback

Many bad releases never take traffic. A failed build leaves the previous release running, and a release has to pass its readiness gate and hold it before cutover. A rollback is for the release that passed those checks and still misbehaves: errors after cutover, a broken page, a slow endpoint.

Roll back

1. Step 1Find the bad deploy

   Deploy history is one row per attempt, newest first, with the commit, branch and author for git push deploys.

   levelrail-cli apps deploys list web --limit 10

2. Step 2Read what went wrong

   show prints one attempt, the newest by default, with its structured failure: the code, the cause, the failing step, a redacted log excerpt and a suggested fix.

   levelrail-cli apps deploys show web
   levelrail-cli apps deploys show web <deploy-id>

3. Step 3Cancel it if it has not cut over

   A queued or running deploy can be canceled before it touches the serving release. Once it has written its desired state, cancel answers 409 and a rollback is the way back.

   levelrail-cli apps deploys cancel web <deploy-id>

4. Step 4Roll back to the previous good deploy

   Without --image, rollback picks the newest successful deploy whose image differs from the one running now. In the dashboard, the same is the Rollback button on a deploy history row, or Roll back to last good on a failed attempt.

   levelrail-cli rollback web

5. Step 5Or go back to an exact deploy

   rollback-to redeploys the exact image a past successful deploy recorded, pinned by digest, with that deploy's config, through the same readiness gate as any deploy. --watch follows it until it takes traffic or fails.

   levelrail-cli apps deploys rollback-to web <deploy-id> --watch

6. Step 6Confirm it landed

   A rollback request returns as soon as the server accepts it. Check the app's status, and read the timeline for the rollback next to the deploys and config changes around it.

   levelrail-cli apps status web
   levelrail-cli apps timeline web

7. Step 7Find the cause before you redeploy

   diagnose explains a failed deploy or a crashloop and lists fixes; --apply-fix applies one by its number. With a git source, push the fix and it deploys through the same gates.

   levelrail-cli apps diagnose web

8. Step 8Let the next one roll itself back

   Automatic rollback on a crashloop is opt in per app, and it works out the last known good release itself.

   levelrail-cli apps auto-rollback enable web
   levelrail-cli apps auto-rollback status web

The post deploy watch

For a few minutes after cutover, each release is watched for an out of memory kill, repeated restarts and a high share of 5xx answers through the ingress. The watch mode decides what a trip does: off does not watch, notify sends an alert, and auto also rolls back to the last good release with its config. The server wide default is notify, set by APP_DEPLOY_WATCH_MODE, and each app can override it.