---
title: "Release and recovery"
description: "Define simple release checks, rollback limits, and data recovery steps before a production incident."
url: "https://architecture.mnppi.org/delivery/release-and-recovery/"
status: "Current"
last_updated: "2026-07-23"
---

# Release and recovery

**Standard details**

- Status: Current
- Reviewed: July 23, 2026
- Cadence: Test at least twice each year

A release process must answer three questions:

1. What changed?
2. Is the service healthy?
3. How will the owner recover?

## Normal release

1. **Merge a valid pull request.**

   Confirm that all required GitHub checks pass.

2. **Watch the Cloudflare build.**

   Confirm that Workers Builds uses the merged commit.

3. **Check the service.**

   Test the public entry point and one critical path.
   Review errors and latency.

4. **Record the result.**

   Keep the commit, deployment result, and any migration result.

## Recovery decision

Use a code rollback when the previous code still supports the current data.
Use a roll-forward when data or bindings make rollback unsafe.

Treat a database migration as a separate recovery problem.
Reverting Worker code does not reverse a D1 schema or data change.

## Required recovery information

- The current and previous deploy identifiers.
- The last known healthy commit.
- The migration state.
- The affected bindings and routes.
- The rollback or roll-forward action.
- The health check that ends the recovery.

## Test schedule

Test code recovery at least twice each year.
Test database backup and restore when a project uses important D1 data.

High-risk projects need a shorter schedule.
They can also require a human release gate or a staged production rollout.