Phase 5 · Staging deploy

The first time the app runs on a real server. Staging is the rehearsal: everything is validated here before production is ever touched — provisioning, DNS, the first release, the web installer, schema parity, a proven rollback, and a monitoring window long enough to catch the slow failures a quick smoke test never sees.

Phase 5 — local app → validated staging

Pages 1–6 are the MUST path and carry the phase gate (page 6). Pages 7–9 are SHOULD/optional quality tracks. Staging only — production is a separate gate (Phase 12).

Gate

The app is live on staging, the staging schema matches local, a one-command rollback has been proven to work, and monitoring is stable across a 24–48h window. No production access happens in this phase.

One hard-won lesson gates the very first step:

Run the preflight — a real deploy died without it

A live run failed at deploy:vendors because the server’s running PHP SAPI was a minor version below what a package required — the earlier check only verified Deployer’s bin/php, not the version the web server actually executes composer install as. The deploy aborted cleanly (the smoke test never ran, the symlink never switched, the live release stayed up), but the round-trip was avoidable. Preview the plan and triple-check PHP first: a preflight failure is cheap; a mid-deploy failure is not.

dep deploy staging --plan        # Deployer 7 uses --plan (the old --dry-run was removed)
ssh <staging-alias> "php -v"     # the web SAPI that actually runs composer install
# On SSH blocks after Phase 6 page 3, use $PHP_BIN (from STAGING_PHP_BIN) instead of bare php.

On shared hosting the web-serving PHP is set per-domain in the control panel, not by the bin/php path in deploy.php. If the panel shows a version lower than composer.json requires, upgrade it there before deploying.

Optional tasks are never silently skipped

Pages 7–9 are SHOULD / OPTIONAL — recommended, not auto-skipped.

• Running interactively: ask before skipping any optional task — “Page 7 (ServerSync) is optional. Include it?”
• Running a batch of phases: the first phase-level choice carries forward (for example, “do all” or “skip all optional”).
• Always list what was skipped at the end, even in fast mode. Silence is not a skip log.

This phase, page by page

MUST — pages 1–6 (the gate lives on page 6):

1 · Pre-flight & provision host Canonical pre-flight (plan preview + PHP triple-check), staging branch, deploy tree, .user.ini limits, shared .env (APP_KEY empty).

2 · DNS + SSL Create the staging subdomain and confirm a valid TLS chain before deploying.

3 · First release Atomic deploy, APP_KEY + optimize:clear, the .env symlink BLOCKER, demo content, installer perms.

4 · Installer + harden Unblock /install, run the wizard against the staging DB, verify, then re-block + re-harden.

5 · Schedule, migrations + schema Install + verify the every-minute cron (preset trap), verify migrations, export + diff the schema.

6 · Rollback + monitor Prove rollback, run the full monitoring sweep across 24–48h + 3 journeys, clear the phase gate.

SHOULD / OPTIONAL — pages 7–9 (quality tracks, after the gate):

7 · ServerSync capture 🟡 Capture installer-made server files back into Git — workflow parity, clear_paths audit, PR review.

8 · Deep codebase audit 🟡 Composer audit, Git hygiene, FVDUT, secret + debug scans, storage triage, frontend anti-patterns.

9 · Atlas Cloud (optional) 🔵 Versioned schema tracking — baseline, push, apply, CI. Requires a license; free fallbacks noted.

Next

A staging deploy that survived a proven rollback and 24–48h of monitoring is the evidence base for Phase 6 · SuperAdmin setup and everything after. If you need to revisit how the release pipeline itself is wired, that lives back in Phase 4 · Deploy pipeline.

Choosing the production path

Configure branding, SMTP, payments, plans, and admin settings on staging first (Phase 6). Then pick how many phases to complete on staging before the production cutover — the choice is a speed-vs-hardening trade-off, not a one-way door:

Path	When to use	Flow
A — Fast launch	Need production ASAP	Phases 1–6 on staging → deploy to production → Phases 7–10 on staging → redeploy
B — Hardened launch	Want everything right first	Phases 1–10 all on staging → deploy to production → verification
C — Iterative	Prefer gradual refinement	Phases 1–6 → deploy to production → Phases 7–10 on staging, redeploy after each batch

Production deploy is its own gate: Phase 12 · Production. No production access happens in Phase 5.