Rolling back a deploy

LaunchPad gives you two safety nets for a bad deploy: automatic image rollback, and database rollback from the pre-deploy backup.

Automatic rollback

After cutover, LaunchPad health-checks the new release against /readyz. If that fails, it automatically rolls back to the previous image — the broken release never keeps serving traffic. If there's no previous image to fall back to, the deploy is left failed and an attention item is opened for manual recovery.

Rolling back the database

A failed migration usually needs the data rolled back too, not just the image. If the app's database has pre-deploy backups enabled, LaunchPad took a snapshot immediately before the deploy. Restore it from the database's Backups view — the default swap restore brings up a copy, verifies it, then swaps, so the rollback itself can't corrupt production. See Restoring a backup.

Good practice

• Keep pre-deploy backups enabled on production databases — it's what makes a one-click data rollback possible.
• Make migrations backward-compatible where you can, so an image rollback alone is safe.
• After any rollback, confirm /readyz is green before sending traffic back.