Question
Instant Rollback vs Rebuild from Git for a bad production deploy with changed build settings
Neel Moss
0 reputation · 22 Apr 2020, 07:13 UTC
44.5K views
Loading…
0 reputation · 22 Apr 2020, 07:13 UTC
Netlify hosts sites as immutable atomic deploys built from a connected git repository. There is no user-managed backup restore for site files; recovery relies on deploy history and the source repository. Forms, Identity and Large Media are stored separately.
For a production revert after a bad release, two documented approaches exist. Instant Rollback republishes a previous successful deploy without rebuilding, which offers the fastest path to restore a known good artifact. Rebuild from Git fixes the source commit and triggers a new build, allowing code and configuration to be corrected before publishing.
The decision is unresolved when the bad deploy also changed build settings or environment variables. Instant Rollback restores prior artifacts but leaves the source and configuration divergent, while Rebuild from Git aligns source truth at the cost of build time. Verification of recovered data is limited to deploy logs, preview URLs and post-deploy checks, as file-level diff or checksum verification for published deploys is not provided.
Which approach preserves the intended build configuration when environment variables were altered in the bad release? How does plan-dependent deploy history retention affect the availability of Instant Rollback for older deploys? What signals confirm the published deploy matches the intended recovered state without file-level diff?
35275 reputation · 22 Apr 2020, 09:31 UTC
To preserve the build configuration and environment variables used in a previous successful release, Instant Rollback is the correct approach. Because Netlify deploys are immutable atomic artifacts, rolling back republishes the exact files and settings that existed at the time of that specific build, bypassing the current (altered) build settings and environment variables.
| Feature | Instant Rollback | Rebuild from Git |
|---|---|---|
| Artifact Source | Existing immutable snapshot | New build from source code |
| Build Settings | Uses settings from original build | Uses current dashboard settings |
| Env Variables | Uses values from original build | Uses current dashboard values |
| Recovery Speed | Near-instant | Dependent on build pipeline duration |
The availability of Instant Rollback is strictly tied to your account plan's deploy history retention. If a deploy has been purged or has expired based on the plan's limits, it cannot be rolled back; in such cases, a Rebuild from Git is the only remaining option, provided the source code is reverted.
Since file-level diffs are not provided for published deploys, use these signals to confirm the recovered state:
Missing Diagnostic: Are the altered environment variables stored in a .env file within the Git repo or configured via the Netlify UI? If they are in Git, a Rebuild from Git is viable after a commit revert; if they are UI-based, only Instant Rollback ignores the current corrupted state.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
netlify