Skip to content

Production Deployment

This runbook describes production. Every command marked MUTATING/REMOTE/PRODUCTION affects live traffic on real domains.

There is no staging tier to rehearse against first - see Infrastructure → Environments. Validate locally (see Local) before merging to main.

Purpose

How a change actually reaches akshayagroupglobal.com and its sibling domains, and what to verify before and after.

Architecture/context

Production deployment is automatic on push to main - not manual, despite what the README says. See CI/CD → Deployment for the full evidence and both deploy paths' exact behavior.

Preconditions

  • PR merged to main, or deploy-cloudflare.yml deliberately dispatched by a maintainer.
  • validate job (see CI/CD → CI) passing - this is enforced automatically for Path 1, but not for Path 2 (manual dispatch skips validate entirely - run it yourself first: npm run build && npm test).

Git branch

main only. This repository has no release/* or staging branch convention.

Required secrets

CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID (both workflows); CLOUDFLARE_D1_DATABASE_ID (Path 2 only, currently a no-op - see CI/CD → Deployment). Already configured as GitHub Actions secrets for this repository - see CI/CD → Secrets if they need rotation.

Build

Handled entirely inside the workflow - npm run build (all apps) then per-app wrangler deploy. No separate manual build step.

Database consideration

D1 migrations apply before any app/API deploy in both paths, so no app ever runs against a schema it doesn't expect. If a migration is destructive or has no rollback path, treat that as a release-checklist item before merging, not something to catch after.

R2 consideration

No R2 provisioning happens during deploy - the bucket already exists (see Infrastructure → Cloudflare). If a change adds a new R2 key convention, confirm it doesn't collide with the private/ prefix contract in Cloudflare → R2.

Deploy

# Path 1 (normal): merge a reviewed PR to main - deploy-production runs automatically.
git checkout main
git pull
git merge --ff-only <your-branch>     # or merge the PR via GitHub
git push origin main                                                          # [PRODUCTION]

# Path 2 (manual, exceptional use - e.g., redeploying Admin/Embroidery outside a main push):
npm run deploy:admin                                                          # [PRODUCTION]
npm run deploy:embroidery                                                     # [PRODUCTION]
# or dispatch deploy-cloudflare.yml from the GitHub Actions tab for its covered apps.

Verify

npm run smoke:production                                                      # [PRODUCTION, READ-ONLY: GET requests only]
See Operations → Verification for the full endpoint list and how to read a failing result.

Smoke test

deploy-production runs npm run smoke:production automatically as its last step (Path 1 only - Path 2 does not run it, run it yourself). Checks 7 endpoints (all apps except Investors, plus /api/health) - see Operations → Verification.

Logs

npx wrangler tail --config workers/api/wrangler.jsonc                         # [READ-ONLY] production logs, live
npx wrangler tail --config apps/corporate-web/wrangler.jsonc                  # per-app equivalent

Rollback

No automated rollback exists, by design (docs/DEPLOYMENT.md §5). See Operations → Rollback for the manual procedure (redeploy last-known good commit, or git revert on main for permanence).

Security considerations

See Infrastructure → Security - in particular, that any credential capable of this deploy is a production credential, since no staging tier exists to absorb a mistake.