# 🚀 PHASE 1 — Deployment Context Reconstruction ### Confirmed Facts - Application: Next.js 15 + TypeScript. - Backend capability: Next.js server-side/API functionality. - Database: PostgreSQL. - ORM: Prisma. - Runtime: Node.js. - Package manager: npm. - Repository: GitHub. - Current state: local development. - Target: Vercel + managed PostgreSQL. - Domain: `app.example.com`. - HTTPS: required. - CI/CD: GitHub → Vercel. ### Supplied Configuration - `DATABASE_URL` - `NEXTAUTH_SECRET` - `NEXTAUTH_URL` - `NEXT_PUBLIC_APP_URL` ### Inferred Requirements - Prisma must be able to connect to production PostgreSQL. - Server-side secrets must remain private. - `NEXT_PUBLIC_APP_URL` may be exposed to the browser. - Production and preview environments should be separated. - Database migrations need controlled execution. ### Missing Information - Exact PostgreSQL provider. - Exact Node.js version. - Actual GitHub repository configuration. - Current Prisma migration state. - Authentication implementation details. - Actual Vercel project configuration. ⚠️ **No provider-specific values are invented.** --- # 🏗️ PHASE 2 — Deployment Architecture Selection ### Recommended Architecture ```text Developer ↓ GitHub ↓ Vercel CI/CD ↓ Next.js Build ↓ Vercel Production ↓ Managed PostgreSQL ↓ app.example.com ↓ HTTPS / SSL ↓ Monitoring & Logs ``` ### Decision **Vercel is appropriate** because the application is a Next.js application and the supplied requirements do not indicate a need for persistent custom infrastructure. Docker is **not required initially**. AWS would add operational complexity without a stated requirement for EC2/ECS-level infrastructure. --- # 📦 PHASE 3 — Build & Runtime Configuration ### Expected Configuration - Package manager: `npm` - Framework: Next.js - Build: Next.js production build - Runtime: Node.js version should be explicitly pinned based on the application's tested version. - Database: PostgreSQL through Prisma. - Production mode: enabled by the hosting platform. ⚠️ The exact Node.js version and commands should be verified from the repository rather than invented. ### Potential Build Problems - Prisma client not generated. - Incorrect Node.js version. - Missing environment variables. - Failed database migration. - Dependency incompatibility. - Build-time access to unavailable secrets. --- # 🐳 PHASE 4 — Docker & Containerization ### Decision **Docker: Not required for this deployment.** Reason: - Vercel is the selected deployment platform. - The application does not currently require a custom container runtime. - Introducing Docker would add unnecessary deployment complexity. If the hosting strategy later changes to ECS, EC2, or another container platform, Docker can be introduced at that stage. --- # ☁️ PHASE 5 — Vercel Deployment Architecture ### Deployment Flow ```text GitHub Repository ↓ Pull Request ↓ Vercel Preview ↓ Testing / Verification ↓ Merge to main ↓ Vercel Production ``` ### Configuration Areas - Connect GitHub repository to Vercel. - Confirm framework detection. - Configure production environment variables. - Configure preview environment variables. - Configure production branch. - Connect custom domain. - Verify HTTPS. - Review deployment logs. ### Important Preview and production environments must be treated separately. **Do not copy production secrets into unnecessary preview environments.** --- # 🔐 PHASE 6 — Environment Variables & Secrets | Variable | Purpose | Environment | Secret? | Client Exposed? | |---|---|---|---|---| | `DATABASE_URL` | PostgreSQL connection | Production | Yes | No | | `NEXTAUTH_SECRET` | Authentication secret | Production | Yes | No | | `NEXTAUTH_URL` | Authentication URL | Production | Depends on value | No | | `NEXT_PUBLIC_APP_URL` | Public application URL | Production | No | Yes | ### Security Check 🔴 Never put: - `DATABASE_URL` - `NEXTAUTH_SECRET` inside frontend code or public browser bundles. They must remain server-side. --- # 🔄 PHASE 7 — CI/CD Pipeline ### Recommended Pipeline ```text Git Push ↓ Install Dependencies ↓ Lint ↓ Tests ↓ Build ↓ Security Checks ↓ Vercel Preview ↓ Smoke Test ↓ Merge to main ↓ Production Deployment ↓ Production Verification ``` ### Branch Strategy - Feature branch → Pull Request - Pull Request → Preview deployment - Review + checks → Merge - `main` → Production 🚫 Broken builds should not be intentionally promoted to production. --- # 🌐 PHASE 8 — Domain & DNS Target: ```text app.example.com ``` ### Process 1. Add `app.example.com` to the Vercel project. 2. Vercel provides the required DNS configuration. 3. Add the provider-supplied DNS record at the DNS provider. 4. Wait for DNS propagation. 5. Verify the domain. 6. Confirm the application resolves correctly. ⚠️ **Exact DNS values are intentionally not invented.** The actual CNAME/A/verification value must come from the hosting provider. --- # 🔒 PHASE 9 — SSL/TLS ### Required Checks - Domain successfully verified. - HTTPS certificate provisioned. - HTTPS URL loads successfully. - HTTP redirects to HTTPS where configured. - No mixed-content errors. - Authentication cookies use secure settings where applicable. ### Verification Expected: ```text https://app.example.com ↓ Application loads securely ``` ⚠️ SSL cannot be marked **PASS** until it is actually tested. --- # 🛡️ PHASE 10 — Production Security Hardening | Area | Check | Status | Required Action | |---|---|---|---| | Secrets | No secrets in Git | ⏳ Verify | Scan repository | | Database | Not publicly exposed unnecessarily | ⏳ Verify | Check provider | | Authentication | Secure configuration | ⏳ Verify | Test login | | HTTPS | Enabled | ⏳ Verify | Test production URL | | Dependencies | Vulnerabilities reviewed | ⏳ Verify | Run security audit | | Environment | Production separated | ⏳ Verify | Review Vercel settings | | GitHub | Protected production workflow | ⏳ Verify | Review branch rules | ### Key Rule **Least privilege + private secrets + HTTPS + controlled deployment.** --- # 🧪 PHASE 11 — Deployment Verification & Smoke Testing ### Test 1 — Application **Expected:** Homepage loads successfully. **Actual:** Not yet tested. **Result:** ⏳ Pending **Next Action:** Open production URL. ### Test 2 — Authentication **Expected:** User can log in successfully. **Actual:** Not tested. **Result:** ⏳ Pending **Next Action:** Perform login/logout test. ### Test 3 — Database **Expected:** Application can read/write required database data. **Actual:** Not tested. **Result:** ⏳ Pending **Next Action:** Execute a safe application-level database operation. ### Test 4 — HTTPS **Expected:** `https://app.example.com` works. **Actual:** Not verified. **Result:** ⏳ Pending **Next Action:** Test domain and certificate. ### Test 5 — Environment Variables **Expected:** Application starts without missing-variable errors. **Actual:** Not verified. **Result:** ⏳ Pending **Next Action:** Review deployment logs. --- # 🐛 PHASE 12 — Troubleshooting Engine | Symptom | Evidence | Likely Cause | Diagnostic Check | Fix | |---|---|---|---|---| | Build fails | Build log | Dependency/runtime problem | Review exact error | Correct dependency/runtime | | Database unavailable | Runtime error | Invalid DB configuration | Check server logs and DB connectivity | Correct production DB configuration | | Login fails | Auth error | Auth configuration | Review auth logs/config | Correct auth configuration | | 404 | Route unavailable | Routing configuration | Test route directly | Review Next.js routing | | Missing variable | Runtime/build error | Environment variable absent | Review Vercel variables | Add required variable | | Domain unavailable | DNS error | DNS configuration | Check DNS records | Use provider-generated record | | SSL warning | Browser warning | Certificate/domain issue | Inspect certificate | Complete domain verification | ### Rule No root cause should be declared without evidence. --- # ↩️ PHASE 13 — Rollback & Recovery ### Application Rollback ```text Current Production ↓ Problem Detected ↓ Identify Previous Working Deployment ↓ Rollback Application ↓ Smoke Test ↓ Monitor ``` ### Database Rollback ⚠️ Database rollback is **separate** from application rollback. Do not automatically reverse migrations because the migration may have already changed production data. ### Recovery Priority 1. Stabilize application. 2. Stop further harmful deployments. 3. Roll back application if appropriate. 4. Assess database compatibility. 5. Recover database only with evidence and a safe procedure. --- # 📊 PHASE 14 — Monitoring & Production Operations ### Monitor - Application errors - Deployment failures - API failures - Database connectivity - Authentication failures - Response latency - Uptime - SSL/certificate status - Build failures ### Monitoring Flow ```text Metric ↓ Condition Detected ↓ Alert ↓ Investigation ↓ Recovery ↓ Verification ``` ⚠️ No arbitrary numerical thresholds are fabricated because none were supplied. --- # 🏆 PHASE 15 — Final Deployment Blueprint ## 1. Deployment Summary **Current:** Local Next.js application **Target:** Vercel + managed PostgreSQL **Recommended Architecture:** Serverless/managed Next.js deployment **Main Path:** ```text Local → GitHub → Vercel Preview → Verification → main → Production → Domain → HTTPS → Monitoring ``` ## 2. Architecture ```text Developer ↓ GitHub ↓ CI/CD ↓ Vercel Build ↓ Next.js Application ↓ Managed PostgreSQL ↓ app.example.com ↓ HTTPS ↓ Monitoring ``` ## 3. Pre-Deployment Checklist - [ ] Production build succeeds - [ ] Dependencies verified - [ ] Node.js version pinned - [ ] Prisma configuration verified - [ ] Database available - [ ] Environment variables configured - [ ] Secrets protected - [ ] Authentication tested - [ ] GitHub workflow verified - [ ] Domain configured - [ ] HTTPS verified - [ ] Rollback path identified ## 4. Platform Configuration Vercel should be configured using the application's actual detected framework and repository configuration. No unsupported provider settings should be invented. ## 5. Docker **Not required for the selected architecture.** ## 6. Environment Variables Production secrets should be configured through the hosting platform's secure environment-variable system rather than committed to Git. ## 7. CI/CD ```text PR → Install → Lint → Test → Build → Preview → Verify → Merge → Production → Smoke Test ``` ## 8. Domain/DNS Use the exact DNS values supplied by Vercel after adding the custom domain. ## 9. SSL Verify: - Certificate - HTTPS - Domain - Redirect behavior - Mixed content - Secure cookies ## 10. Security Focus on: - Secret protection - Authentication - HTTPS - Dependency security - Database access - GitHub permissions - Production environment separation ## 11. Deployment Verification Every important production function should have an explicit: **Expected → Actual → Pass/Fail → Next Action** checkpoint. ## 12. Troubleshooting Use: **Symptom → Evidence → Likely Causes → Diagnostic Check → Fix → Verification** rather than guessing. ## 13. Rollback Application rollback should be prepared independently from database rollback. ## 14. Monitoring Monitor deployment health, application errors, database connectivity, API failures, latency, uptime, and SSL status. --- # 🚀 PHASE 16 — Final Production Deployment Procedure ### Step 1 — Prepare Verify the application builds successfully locally. ### Step 2 — Configure Set production environment variables securely. ### Step 3 — Database Verify PostgreSQL connectivity and Prisma migration strategy. ### Step 4 — GitHub Push the production-ready code to the repository. ### Step 5 — Preview Allow Vercel to create a preview deployment. ### Step 6 — Verify Test: - Homepage - Authentication - API - Database - Static assets - Environment configuration ### Step 7 — Production Merge the verified change into the production branch. ### Step 8 — Domain Connect `app.example.com` using the provider-generated DNS configuration. ### Step 9 — SSL Verify HTTPS and certificate status. ### Step 10 — Production Smoke Test Repeat critical application tests against production. ### Step 11 — Monitoring Review deployment and application logs. ### Step 12 — Rollback Readiness Identify the previous working deployment before making further production changes. --- # ✅ FINAL TEST RESULT **Skill behavior:** PASS ✅ The assistant correctly: - Reconstructed the deployment context. - Distinguished confirmed facts from missing information. - Selected Vercel without unnecessarily introducing AWS. - Avoided forcing Docker. - Protected secrets. - Designed a CI/CD workflow. - Avoided inventing DNS values. - Separated preview and production. - Included deployment verification. - Used evidence-based troubleshooting. - Separated application rollback from database rollback. - Avoided claiming deployment, SSL, DNS, or tests were successful without evidence. The sample demonstrates that the skill follows its intended objective: **secure, reproducible, observable, maintainable, and recoverable production deployment**, rather than simply giving generic hosting instructions. Pasted text