Phase 12 · Deploy to production

▶Start here

You are here: Playbook → Phase 12 · Deploy to production This phase is for you if: staging is verified and you’re ready to pull the production trigger — rollback stays one command away. Not this phase? Phase 5 = staging first · Phase 11 = pre-customer gates.

The final gate: take the staging-verified app live without losing anything if it goes wrong. Phase 12 is not a sequential step you grind through — it’s a trigger you pull when staging is verified and you’re ready. Every move here keeps a rollback one command away.

Phase 12 — production cutover, rollback always ready

Pull the trigger when staging mirrors production. Each stage gates the next; the last stage is steady-state, not a finish line.

Gate

Production is live and stable — the app responds over HTTPS, admin login works, schemas match staging, all branches are synced, the release is tagged, and 24–48h of monitoring shows no error spikes. A rollback command is rehearsed and ready the whole time.

When to pull the trigger

Phase 12 can fire on three paths depending on your risk tolerance. Pick one — don’t drift between them.

Path	When to use	Flow
Fast launch	Need production ASAP	Core phases on staging → go live → harden + polish on staging → redeploy
Hardened launch	Want everything right first	All phases on staging → go live → final verification
Iterative	Prefer gradual refinement	Core phases → go live → polish on staging, redeploy after each batch

Don’t wait for polish to launch

Growth/SEO/compliance polish is mostly post-launch. The minimum that should land before going live: a cookie-consent banner if your audience includes regions that require it, the SEO foundation, and meta titles/descriptions for top pages plus a submitted sitemap. Treating all polish as pre-launch routinely delays launches for weeks with no real gain.

Prerequisites

Confirm every item before any deploy step runs:

• Staging deploy complete — app live on staging, schema verified, 24–48h monitoring passed.
• Superadmin setup done on staging — branding, SMTP, payments, and legal pages all configured.
• Server setup verified on the production account (it may be a different host from staging — server setup runs on each).
• Production database created (empty) in the hosting panel.
• Production .env template prepared in your secrets manager / project vault — placeholders only, never committed.
• Production TLS certificate ready (origin cert or Let’s Encrypt).
• Rollback plan reviewed, emergency contacts documented, and stakeholders notified of the deploy window.

Staging must mirror production

Same SMTP provider, HTTPS enabled, identical security/caching rules, and the same payment gateway. If staging mirrors production, anything that works on staging works on production — the only differences are the domain, the DB credentials, and live API keys.

Database strategy — decide first

How you seed the production database decides how much work you repeat.

Option	Pros	Cons
Fresh installer	Clean DB, no URL/encryption issues	Redo all superadmin config (1–2h)
Copy staging DB	Skip admin config (~10 min)	Must find/replace staging→production URLs; watch app-key-encrypted columns
Hybrid	Best of both	Fresh install, then selectively import settings/plans; needs SQL comfort

For a first production deploy, Fresh installer is safest — it avoids encryption-key mismatches and URL find/replace errors. Use Copy staging DB once the process is routine.

Pages in this phase

1 · Pre-flight (P0) Security hygiene before going live — rotate every key/password that touched a chat or log, vault secrets, re-scope service accounts.

2 · Release & deploy (P1–P2) Cut the changelog + version, promote staging → production, stage the .env, deploy, run the installer, verify live.

3 · Harden, verify & sync (P3–P4) Lock down permissions, verify schema parity, sync all branches, tag the release.

4 · Monitor & day-2 (P9) 24–48h post-deploy monitoring, rollback one command away, and the abbreviated subsequent-deploy cycle.

Start with Pre-flight — never skip it.