Rollback Without Rebuilding the Release You Meant to Restore

Rollback without rebuilding the release you meant to restore

A rollback should reduce uncertainty. Rebuilding last week’s commit with today’s package registry, base image and toolchain introduces new uncertainty at the exact moment the team needs less of it.

The safer target is the previously verified artifact.

Source is not the artifact

Source control identifies human-readable inputs. A release artifact also reflects dependencies, compiler versions, build configuration and generated output. Two builds from the same commit can differ unless the entire environment is reproducible.

Retain the artifact by immutable digest together with enough release evidence to verify its origin. Promotion and rollback can then select identified bytes rather than recreate them.

Compatibility is the hard part

An old artifact may not work with today’s environment. Before restoring it, consider:

• database migrations and whether they are backward compatible;
• secret and binding names expected by the old release;
• external API versions;
• queued messages written by the new release;
• object formats and caches; and
• one-way side effects such as payments or emails.

This is why rollback design begins before deployment. Expand-and-contract database changes, versioned messages and additive configuration create a larger safe recovery window.

Define the trigger and authority

Write down who can initiate rollback, what evidence justifies it and when forward recovery is safer. A small presentation defect may be fixed forward. A rapidly rising error rate after a release may justify immediate traffic restoration.

Automation can recommend or execute within bounded policy, but the decision and actor should remain auditable.

Restore, verify, then route

1. Identify the last known-good artifact and compatible configuration.
2. Deploy it away from normal traffic or to a controlled slice.
3. Verify readiness and the exact release identity.
4. Exercise the critical transaction with safe test data.
5. Shift traffic according to the incident plan.
6. Confirm error and latency recovery.
7. Preserve the failed release and evidence for investigation.

Do not delete the failed evidence during containment. It explains what changed and prevents the same release from being promoted accidentally.

Rollback is not data reversal

Code rollback can stop new incompatible behaviour. It cannot automatically undo an email, refund a charge or reconstruct overwritten data. Those outcomes need idempotency, compensating transactions, backups and tested restore procedures.

BlinkHost’s release model retains identified artifacts and separates deployment from routing. The customer-facing value is simple: a known-good release can be restored without relying on an unrepeatable local build.

Primary references

• Azure Architecture Center: deployment stamps
• Azure Architecture Center: compensating transaction
• SLSA provenance specification
• PostgreSQL documentation: continuous archiving

Reviewed 2 September 2026.