Launch Knowledge Base
Release Safety, Rollback, and Recovery
How to think about release artifacts, versions, rollback, database-safe changes, backups, restore drills, and lightweight incident notes for small teams.
Launching is not only the moment a product goes public. Every future deploy is another launch to existing users. Release safety is the discipline of changing production without making recovery impossible.
For beginners, the most important release question is simple: if this version breaks, can we return users to the last working state?
Artifacts and versions
A release artifact is the thing that gets deployed: static files, a container image, a server bundle, a mobile binary, or a desktop package. A safe release process makes artifacts identifiable.
Useful release metadata includes:
- version or build number
- commit hash
- build time
- environment
- deploy actor
- release notes or change summary
- previous version
This metadata helps answer "what changed?" when a problem appears.
Rollback vs rebuild
Rollback means returning traffic or users to a known previous release. Rebuild means producing a new artifact from source. They are different.
Rollback is safer when the prior artifact is still available and compatible with current data. Rebuild may accidentally include new changes, dependency updates, or environment differences. For web services, the best rollback is often a traffic pointer switch to a previous artifact, not a fresh build from an old commit.
Use rollback when:
- the new release causes user-visible failures
- the previous release was healthy
- no irreversible data migration blocks return
- the fastest safe action is restoring service
Use a hotfix when:
- rollback would break data compatibility
- the previous release also has the issue
- the failure is caused by external configuration that rollback will not change
Database-safe changes
Databases make rollback harder because data changes persist after code changes. If a deploy changes schema and code at the same time, rolling code back may leave the old code unable to read the new schema.
Safer migration habits:
- add columns before requiring them
- deploy code that can handle old and new shapes
- backfill data separately when possible
- remove old columns only after old code is gone
- avoid destructive migrations during risky launches
- test restore or rollback path for critical changes
The simplest first-launch rule: avoid irreversible production data changes unless you have a backup and a clear reason.
Backups and restore
A backup is not a recovery plan by itself. You need to know how to restore it, how long it takes, and what data would be lost.
For small teams:
- enable provider backups for production databases
- know retention period
- know how to export critical tables or collections
- restrict who can delete production data
- test restore in a non-production environment when practical
- document manual repair actions after incidents
Backups should be protected. A leaked backup can expose as much data as a leaked database.
Feature flags and staged rollout
Feature flags let you turn behavior on or off without deploying new code. Staged rollout releases a change to a subset of users or traffic first. These tools are useful, but they add their own complexity.
For a first launch, a simple flag can help hide incomplete functionality or disable a risky integration. Avoid building an elaborate flag system before the product needs it. Every flag must still be tested in both states.
Lightweight incident notes
An incident note does not need to be formal to be useful. After a failure, write down:
- what users experienced
- when it started and ended
- what changed before it happened
- how it was detected
- how service was restored
- what will prevent the same failure next time
The point is learning. A small team that records incidents improves faster than a team that only remembers them vaguely.
Pre-release safety checklist
- Previous working artifact is available.
- New artifact has a version or commit id.
- Deployment path is known.
- Rollback path is known.
- Database migration is reversible or safe for old and new code.
- Production environment variables are set.
- Smoke test path is clear.
- Logs can be inspected during and after deploy.
- Someone owns the decision to rollback if needed.
Flash Launch note
Flash Launch presents rollback as a product capability because rollback is part of launch success. A platform that can deploy but cannot recover is incomplete. The safest experience is one where every deploy creates a visible history and a known return point.