Phase 4 · Deploy pipeline
Build the machinery that ships your app. After this phase, dep deploy staging produces a working site — because the deployer, server access, domains, SSL, and the production .env all exist and are verified.
Phase 4 — from runnable app to deployable pipeline
Clearing that gate safely is exactly what the warning below is about.
This phase, page by page
Section titled “This phase, page by page” 1 · Deployer (zero-downtime) MUST. Install Deployer and author deploy.php — atomic releases, shared storage/.env, hooks, server PHP paths, SSH dry run.
2 · Subdomains + SSL MUST. Point staging + production at the server, provision certs, and get HTTPS green with a five-check verification.
3 · Production .env MUST. Assemble the env as a Deployer shared file — bidirectional drift check, Git-history secret scan, production caches.
4 · CI + ServerSync SHOULD. GitHub Actions deploy + ServerSync — secrets, clear_paths ↔ GIT_ONLY_PATHS symmetry, actionlint.
5 · DNS email records SHOULD. SPF / DKIM / DMARC (+ MX) for deliverable transactional mail; CAA deferred to Phase 7.
6 · Cloudflare CDN SHOULD. Free-plan edge — Full (Strict) SSL, HSTS, WAF, rate limiting, cache rules, DNSSEC. Rocket Loader OFF.
7 · Release + incident response SHOULD. Changelog + version bump + release tag, then an incident runbook wired dev-only into the repo.
A working pipeline means you can do a real, observed deploy — that’s Phase 5 · Deploy to staging, where the app goes live on a server for the first time.
Source: distilled from the Phase 4 deploy-pipeline reference (Tasks 35–42). Exact
deploy.php, DNS, and CDN configs live in the reference set.