ioy.ai5. Verify and deploy
Move from local evidence to an isolated preview, then prepare production.
Can Codex handle the setup for me?
Yes. Template 1.3.1 adds a guided launch workflow: validate the local product, deploy isolated Cloudflare preview resources, bind and verify formal HTTPS, configure Google login/One Tap, GA4 and Search Console, connect email/models, set up the selected payment provider in sandbox, then deploy and verify production. Codex reuses account choices and existing authorization. Account ownership, two-factor checks, missing permissions, merchant reviews and registrar changes still need the account holder.
npm run launch:plan -- --config wrangler.jsonc --provider waffo --billing-env test
npm run cloudflare:launch -- --config wrangler.jsonc --zone <zone-id>
# Add --apply after preparing independent bindings, Secrets and migrations.
npm run launch:verify -- --config wrangler.jsoncThe Cloudflare helper checks domain ownership and existing DNS/Worker routes before invoking the guarded deployment. Google setup checks current HTTPS first, reuses matching GA4 resources, appends a separate verification TXT and submits the sitemap. Configure customer OAuth clients through Google Auth Platform; operator API scopes and project/property roles are separate from customer login. Stripe and Creem use official CLIs, while Waffo uses its official Skill and installed SDK. The repository README and builder Skill contain the branch instructions and key configuration.
A preview on a formal domain prepares integrations; it remains a preview, with unconfigured capabilities disabled. A GA4 collection receipt does not prove Realtime reporting, and a submitted sitemap does not prove indexing.
Know what each check proves
Local simulation proves the workflow. A build proves the bundle can be produced. A sandbox payment proves a provider test flow. None alone proves a production product is ready.
First run:
npm run check
npm run content:check
npm run i18n:check
npx playwright install chromium
npm run test:uiUpdate reference acceptance cases when you change modules or rules. Check real output files and cross-user access, not just a success label.
Create preview resources
In your new product directory:
npx wrangler login
npx wrangler whoami
npx wrangler d1 create my-saas-preview-db
npx wrangler r2 bucket create my-saas-preview-filesEnter the returned database name/UUID and bucket name in wrangler.jsonc. Set an independent Worker and Workflow name, APP_ENV=preview, the actual APP_URL, and the configured service settings from step 4. Keep code binding names DB, FILES, EMAIL, JOBS, ADMISSION, ASSETS unchanged.
Deploy and inspect preview
Rebuild after configuration changes, write that Worker's secrets, then:
npm run db:remote
npm run deploy:check
npm run deploy
npm run deploy:verify -- --url https://preview.example.comReplace the example URL with your real preview address. Migration writes the configured remote database. deploy:check is a dry-run; deploy actually deploys. Preview is excluded from indexing.
Verify received email, Google OAuth/One Tap, sandbox checkout and webhook, actual AI output, GA4 delivery, administrator TOTP, private files and backup restore. The URL verification script checks HTTP resources; it does not complete these provider workflows for you.
Prepare production separately
After acceptance, create independent production resources and credentials. Set APP_ENV=production, real domain, live payment IDs/keys and intended live capabilities. Do not reuse preview data. Run npm run doctor; it lists reference release requirements and does not validate secrets. The current release gate expects live model/billing, Turnstile, GA4 and a live price mapping.
Back up the target database, apply tested migrations, then use npm run deploy -- --production. Run URL verification and real production checks again, recording the deployed version. Keep financial/provider evidence separate from local tests.
Keep a recovery path
Backups contain personal data and must stay private. D1 SQL does not include R2 bytes, so save files separately. Restore only to an isolated non-production database first. A Worker rollback does not undo a database migration. Full commands and operator acceptance criteria are in the repository README, docs/operations.md and docs/acceptance.md.