Use this page to understand the operating boundary, then follow the production delivery runbook for the commands and checklist.
Assign operational responsibility
| Layer | Owner | Required evidence |
|---|---|---|
| Application and Vercel | Auth, routes, native deployment | Deployment ID, migration result, allowed/denied path |
| Database | Schema and data health | Ordered migrator result and compatibility evidence |
| Fly components | Operator-selected images and private workers | Exact tag, Machine record, and role health |
| RunPod worker | Managed deployment processing | Exact tag, Machine record, and private worker health |
| Runtime and store | Sessions, events, outcomes, replay | Known-session completion and inspection |
| Providers | Registry, qualification, and models | Profile/model readiness and short run |
| Production owner | Protected-branch decision and rollback | Reviewed change and provider evidence |
Advance production
Merge the reviewed change to main, then advance the protected production branch. Vercel natively deploys one and docs. Fly, RunPod worker, and tenant runtime targets do not react to the branch change.
Preflight migrations
Run the dedicated database job with only the unpooled production connection. Apply ordinary ordered migrations and preserve expand/deploy/contract compatibility.
Operate each target manually
Choose a readable operator tag and publish only the intended image roles. Update one exact Fly Machine or tenant Environment at a time. Managed RunPod profile changes are separate administrative operations. Nothing selects, rebuilds, deploys, or promotes another target automatically.
Verify workers and Environment runtime canaries
Verify every deployed Machine's selected tag and provider-native health result. When Router or Workspace Runtime changes, update one canary Environment through its durable lifecycle, run the existing live Workspace and Preview proofs, and explicitly activate that pair. Do not update the remaining fleet automatically.
Record evidence
Retain the operator, intended scope and tag, Vercel deployment IDs, migration result, Fly Machine before/after records, worker health, canary operation, activation result, and timestamps. Keep credentials and private reasoning out of the record.
Roll back or fix forward
Use Vercel's native rollback for its own projects. Redeploy each selected Fly Machine with its recorded prior tag. Return Router and Workspace Runtime to the prior tag only through the same canary-first manual process. Never reverse data migrations destructively; stop and fix forward when rollback cannot preserve data contracts.
Continue with Production delivery, Migrations, and Troubleshooting.