Roll back a deploy

If a deploy breaks your app, you can put an earlier healthy version back in production in one click. ScaleBop starts your own deploy workflow in GitHub Actions. It runs that version’s app code with your current infrastructure. ScaleBop never deploys into your AWS account itself.

Roll back from ScaleBop

1. Open your project and go to Deployment history.
2. Find the version you want back. You can roll back to any deploy that finished healthy and is not the version running now.
3. Choose Roll back to this version, read the summary and confirm.

GitHub Actions runs the deploy. When it passes the health check, the history shows the run with a Rollback · restored abc1234 badge, and Ship changes shows that production is running an earlier version.

You can’t start a rollback while another deploy is running: it would wait behind that deploy, and a push to production in the meantime would take its place. Wait for the current deploy to finish first.

What a rollback changes

• Your app’s code goes back to the version you picked.
• Container apps reuse the image that version deployed. If that image is no longer in your ECR repository, the workflow builds it again from that commit, with the Dockerfile ScaleBop generates today if your app uses one, and says so in the run summary.
• Static sites and Next.js apps are built again from that commit with today’s build settings, then published.
• Auto-ship is paused if it was on, so the next commit from your AI tool doesn’t undo the rollback. Turn it back on under Ship changes when your fix is ready.

What a rollback does not undo

• Infrastructure. Your CDK stack stays as it is today: domains, task size, alarms and every other resource. Only the app code goes back.
• Environment variables and secrets. The earlier code runs with today’s values.
• Your database. Migrations and data written since that version stay. The earlier code runs against today’s schema, so check it can still read the data before you roll back past a migration.
• The production branch. It stays where it is, so git still shows the newer commit. ScaleBop does not rewrite your branches.

If you need to undo an infrastructure change, revert the commit in git and use Ship changes.

Roll forward again

When your fix is on your default branch, use Ship changes. If the fix is already on production, use Redeploy production. Either one deploys the head of production again, and the rollback notice goes away.

Roll back from GitHub without ScaleBop

Your workflow can roll back on its own:

1. In your repository, open Actions → Deploy Generated App → Run workflow.
2. Pick the production branch.
3. In rollback_sha, paste the full 40-character commit SHA of the version you want back. It must be an earlier commit on production.
4. Leave scalebop_attempt_id empty and choose Run workflow.

The run checks out that commit’s app code with today’s infra/, scalebop/ and .scalebop-deploy/ folders, then deploys as usual. ScaleBop still records it in your deployment history as a rollback.

If the button isn’t there

• The deploy workflow is older than rollback. If ScaleBop says your workflow needs an update, choose Update setup, merge the pull request, then try again.
• The version predates your current setup. The setup check runs for rollbacks too. If an earlier version can’t run on today’s setup (for example, it has no Dockerfile and your app now deploys as a container), the run stops before it deploys. Revert the breaking commit in git and use Ship changes instead.
• No healthy deploy to go back to. You can only roll back to a version that deployed healthy at least once.