Release and recovery

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.