How To Restore A Production Deployment

Use this guide to restore a known-good VyDex production deployment after an unsuccessful deployment. Routine deployment does not attempt automatic rollback. You need maintainer access to the Cloudflare Pages project vydex and the matching repository release state.

This is an emergency recovery task. To test rollback and restoration under normal conditions, use How To Rehearse The Production Rollback.

Before You Start

Stop other production deployments and rollback attempts.
Find the exact intended Cloudflare deployment ID in the Cloudflare dashboard, failed rehearsal run, or vydex-rollback-evidence-* artifact.
Confirm that the target is a successful Production deployment for the Pages project vydex. Never select a preview deployment.
Identify the VyDex Release ID served by the deployment and select its matching descriptor and manifest under generated/release-data/releases/{release-id}/. The deployment commit is separate operational provenance.
Confirm the expected VyDex Release ID, canonical origin, Entry count, immutable Dataset path, routes, redirects, and file inventory before changing production.
In a clean checkout of the matching commit, run npm ci and install the pinned Chromium runtime with npm run test:browser:install before using the hosted verifier.

Do not choose a deployment because its Homepage looks correct. The target must represent one complete committed release. Cloudflare deployment IDs may differ while the VyDex Release ID and artifact bytes remain the same.

Restore The Deployment

Open the Cloudflare dashboard and select Workers & Pages.
Open the Pages project named vydex, then open Deployments.
Find the successful production deployment with the intended deployment ID and matching commit.
Open that deployment's actions menu and select Rollback to this deployment.
Review the target ID before you confirm. This action changes the live production site.
Confirm the rollback, then wait until Cloudflare marks the selected deployment as the current production deployment.

If a failed rehearsal printed a manual recovery command, you may use that command instead of the dashboard. Keep $CLOUDFLARE_ACCOUNT_ID and $CLOUDFLARE_API_TOKEN as environment-provided values; do not paste either secret into a tracked file, issue, report, or chat message.

Confirm The Restored Release

Confirm in Cloudflare that canonical_deployment.id matches the intended deployment ID.
Open https://vydex.pages.dev and confirm that the Homepage loads.
Open the Export JSON page and confirm that its Release ID, Entry count, and immutable download URL match the selected manifest.
Open the immutable Dataset and Schema URLs from the manifest. Confirm that each returns JSON rather than an error page.

Use the matching repository commit to run the hosted verifier with VYDEX_EXPECTED_DEPLOYMENT_ID set to the restored Cloudflare deployment ID:

$env:PUBLIC_SITE_ORIGIN = "https://vydex.pages.dev"
$env:VYDEX_EXPECTED_DEPLOYMENT_ID = "replace-with-production-deployment-id"
npm run verify:hosted-stage-1

The command also requires the Cloudflare Pages environment values described in .env.example. Active release verification may run the complete HTTP, Playwright, and Axe suite up to three times while Pages edges converge. Archived recovery verification uses that release's immutable manifest and route contract.

If Something Goes Wrong

Do not repeatedly choose different deployments. Preserve the intended deployment ID and the failed workflow artifacts, then check whether the target is a successful production record for the correct project and commit.

If Cloudflare cannot make the intended ID canonical, keep the production incident open and do not start the rollback rehearsal. The Hosted Release Verification concept explains the evidence and restoration contract; the Cloudflare Pages Deployment concept explains deployment selection and identity boundaries.

Next Steps