Before going live, verify the production build, access boundaries, data changes, failure handling and rollback. A green deployment proves that the host accepted your release. It does not prove that a second user cannot access another person's data or that a failed payment is handled correctly.
Use the checklist below as a release record. Replace a checkbox with evidence: a command result, an observed screen or a tested recovery step. These are proposed checks for your app, not claims that every app has already passed them.
Copy this release record
# Release checks
- Commit and preview URL:
- Build and relevant tests completed:
- Required production settings checked without copying secret values:
- Signed-out and two-user access checks:
- Invalid input, timeout and retry checks:
- Migration and backup or restore evidence:
- Mobile and keyboard checks:
- Logs and alerts verified with a safe test:
- Known good release and rollback procedure:
- Remaining issues and release decision:
If you have not deployed a preview yet, follow the first deployment walkthrough first. Choose a compatible host using the hosting comparison rather than assuming a static upload can run server features.
Build from a clean environment
- Install the locked dependencies with the repository's package manager and supported runtime.
- Run the relevant checks and production build. Record their actual exit status.
- Check the host's root directory, build command and output against the installed framework and adapter.
- Review new dependencies and generated files in the diff.
Do not append next export to a modern Next.js build command from an old tutorial. Read the version's deployment and static-export guidance. A static export deliberately gives up features that require a server.
A useful result is “the preview built from commit X with the same lockfile,” not “it worked in a development tab.”
Verify configuration without publishing secrets
- Required variables are present in the intended preview and production environments.
- Public browser configuration contains only values intended to be public.
- Auth callbacks, email links and payment webhooks use the intended domain and environment.
- No live secret is committed in source, a generated asset or Git history.
Search for development URLs as a review aid. A match in documentation can be legitimate; a hardcoded API destination in production code may be a bug. If a secret was exposed, rotate it through the appropriate provider. Deleting the current line does not invalidate the old credential.
Test access with two separate users
Create disposable accounts A and B in a staging environment. Give each account a private record and, if applicable, a private uploaded file.
| Attempt | Expected outcome |
|---|---|
| Signed-out request to a protected operation | Denied without exposing private data |
| A reads A's record | Allowed |
| B substitutes A's record ID in a request | No record returned or access denied |
| B tries to update or delete A's record | No change to A's data |
| B requests A's private file | Denied unless A deliberately shared access |
| A signs out, then refreshes a protected deep link | Access requires sign-in again |
Inspect the underlying response and stored data. A hidden button is not authorization, and an update returning no error does not prove that a row changed. Public endpoints can legitimately remain public; classify each operation before testing it.
The authentication testing guide covers session and recovery paths. For Supabase, use the RLS guide to check database boundaries. OWASP recommends validating authorization on every request.
Exercise failed and repeated actions
- Submit empty, malformed and oversized input. Validation explains what to fix and writes no invalid record.
- Simulate a dependency timeout in staging. The app exits loading state and offers a useful next step.
- Submit a state-changing action twice. Confirm it cannot duplicate a payment, reservation or message.
- Retry after a failure. Confirm bounded retries and a total timeout, with idempotency for operations that require it.
- Check success messages against actual service results. Accepted requests and completed actions have different states.
Customer-facing errors should describe the useful next action. Keep raw exceptions, credentials and private response details in restricted diagnostics.
Plan data changes and recovery together
- Apply migrations to a test environment with representative data first.
- Verify the migration's effect and compatibility with both the old and new application during rollout.
- Confirm a usable backup or export and test the required restore procedure.
- Identify the known good application release and rehearse its restoration.
“Run all migrations first” is too broad: some releases need an expand-and-contract sequence so old and new code can coexist. An application rollback usually does not reverse data writes or schema changes. Record who makes that decision and how data will be protected.
Check the browser and delivery
- Open the important routes directly, including a nested route and a missing page.
- Check narrow and wide screens, keyboard order, visible focus and zoom.
- Open menus, dialogs and disclosures. Headers toggle across their row; focus returns correctly; each action appears once in its context.
- Inspect loading, empty, error and success states.
- Verify HTTPS and relevant response headers. Introduce CSP deliberately and test the flows it affects.
- Check asset sizes and caching on the production build. Never cache a personalized response as shared public data.
Run mobile performance measurements under recorded conditions. Image dimensions help prevent layout movement; the image needed for the first screen should not be delayed indiscriminately. A checklist alone cannot promise a particular loading-time improvement.
Observe the release
Trigger a safe known event in staging and locate it in your monitoring. Verify that an alert reaches the responsible person. Keep logs useful without recording passwords, tokens or full customer payloads.
After deployment, repeat the core journey on the real domain and watch the release's errors, latency and data integrity. Use the host's production checklist for platform-specific settings. The production readiness guide adds the ongoing ownership, capacity and incident-response questions.