Release and recovery

Status

Current

Reviewed

July 24, 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 does the owner recover?

For a Worker app, that usually means: know the commit and Worker version, check a public route and error rate, and know whether you can roll back code without breaking D1.

Normal release

1. Merge a valid pull request.

   Confirm all required GitHub checks pass.

2. Watch the Cloudflare build.

   Confirm Workers Builds uses the merged commit.

3. Check the service.

   Hit the public entry point and one critical path. Review errors and latency for the new version.

4. Record the result.

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

Recovery decision

Roll back code when the previous Worker still supports the current data. 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. If you added a required column and the old code cannot read the new rows, roll forward.

Required recovery information

• Current and previous deploy identifiers
• Last known healthy commit
• Migration state
• Affected bindings and routes
• Rollback or roll-forward action
• Health check that ends recovery

Test schedule

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

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