Production release checklist for a complete application

Turn code, configuration, data, security, observation, staging, and rollback into verifiable release evidence.

PRODUCTIONINTERMEDIATE35 minutesOutcome: release evidence and two-plane rollback

A successful deploy proves that the platform accepted an artifact. It does not prove the user flow, security rules, data compatibility, or rollback. Cloudflare Workers manages versions separately from deployments. Use that boundary to separate “upload a testable version” from “send production traffic to it.”

Code rollback does not roll back data

A Worker version captures code, static assets, bindings, and compatibility settings. Data changes in D1, R2, KV, and Durable Objects do not follow a version rollback. A release needs separate code-plane and data-plane plans.

Release evidence matrix

Plane	Pre-release evidence	Production signal	Rollback action
Code	Lint, types, unit tests, workerd smoke	Error rate, latency, version ID	Restore a stable Worker version
Configuration	Binding, secret, and compatibility diff	Missing bindings and permission errors	Restore known configuration and secrets
Data	Backup, migration rehearsal, old-code compatibility	Query, validation, and data anomalies	Stop writes, run compatible code, restore data
Security	Rule expression, test path, false-positive threshold	Challenge/block events and user failure	Disable the latest rule
Domain	Read-only DNS/TLS check and cutover window	Resolution, certificate, 5xx	Restore the previous record or route

Before release

Pin inputs and build environment

Lock Node and package-manager versions. From a clean dependency install, run content audit, lint, types, tests, production build, and bundle budget. Preserve artifact identity and commit, not only a screenshot.

Verify a preview version

Use a preview URL or workerd for login, core reads and writes, 404, unauthorized, downstream failure, and static assets. Confirm responses and logs do not leak secrets or stacks.

Apply compatible migrations first

Rehearse D1 migrations against a separate preview database. Prefer expand/contract: add structures old code can ignore, deploy compatible code, move data, then remove old structures after an observation window.

Record rollback triggers

Define thresholds and windows for error rate, critical-flow failure, latency, and business validation. Assign who can roll back, who inspects data, and who owns security rules.

During release

Even a low-traffic application runs a preview smoke before production. Gradual deployments can split traffic across old and new versions while you observe version-specific signals. Account for version skew: consecutive user requests or Worker-to-Worker calls may reach different versions. Schemas and service-binding contracts must be backward and forward compatible during the rollout window.

User flow

Home, login, core create, read, download, and logout.

Failure flow

Invalid input, unauthenticated, unauthorized, 404, and downstream timeout.

Resource state

D1 migration, R2 bucket, Queue consumer, and secrets exist at the right scope.

Observation state

Logs correlate request, version, and stable error code without unnecessary sensitive data.

After release and rollback

Observe real critical paths before increasing traffic. If code signals regress, restore a known stable version. If data has already been written under a new schema, stop additional writes before running the rehearsed data recovery or compatible code. If only a WAF or rate-limit rule produces false positives, roll back that rule alone instead of changing code and database together.

Local project gate example

pnpm content:check
pnpm lint
pnpm types:check
pnpm test
pnpm preview:build
pnpm bundle:check
pnpm smoke
pnpm e2e

These commands verify the Orange Book project. They are not a drop-in checklist for every application. Add your own migration, critical business, and security-rule tests.

Next: return to the complete application path.