Pre Deploy Guardian

Never push to production without checking env vars, secrets, migrations, API stability, and having a rollback plan — automated in one pre-deploy pipeline.

The Problem

Your team deploys on Friday afternoon. The env vars look right. The tests pass. The migration was tested on staging. Then the production API starts returning 500s because the .env.production file is missing a new REDIS_URL variable that was only added to .env.staging. Nobody catches it because there's no systematic pre-deploy check — just a developer eyeballing the diff and hoping nothing is misconfigured. The rollback takes 45 minutes because nobody wrote a rollback plan.

What You Get

• 8-phase validation pipeline — Environment Scan, Code Health, Dependency Audit, Data Layer, API Stability, Security Gate, Rollback Plan, and Deploy Summary — executed sequentially with a traffic-light verdict (GREEN/YELLOW/RED)
• Environment variable detection — compares .env vs .env.example, flags placeholder values (your-, change-me, CHANGEME), and detects staging URLs in production configs
• Dependency vulnerability scanning — runs npm audit, pip-audit, cargo audit, or govulncheck and categorizes findings by severity with blocking rules for high/critical CVEs
• API stability analysis — detects modified response shapes, removed endpoints, and parameter changes by diffing the last 10 commits against API route definitions
• Security gate — scans for hardcoded API keys, .env files in diffs, debug mode enabled, and secrets in git history with specific regex patterns for common credential formats
• Rollback plan generation — produces a structured document with trigger conditions, rollback commands (git revert, Docker rollback, kubectl undo), verification steps, and post-rollback tasks

Why This Beats Prompting It Yourself

When you ask an agent "validate this deployment," it typically checks if tests pass and calls it done. It doesn't scan environment variables for placeholders, doesn't audit dependencies for CVEs, doesn't check if API response shapes changed, and certainly doesn't generate a rollback plan. The 8-phase structure ensures no category is skipped — even when the developer is rushing to deploy before end-of-day.

Example Session

You: Validate this deployment to production.

Agent:

🚀 Deploy Readiness Report

Branch: release/v2.3.0 | Target: Production | Commit: a1b2c3d

| Phase | Status | Issues | |-------|--------|--------| | 1. Environment Scan | ❌ RED | REDIS_URL missing from .env.production | | 2. Code Health | ✅ GREEN | All tests pass, linting clean | | 3. Dependency Audit | ⚠️ YELLOW | 2 medium CVEs in lodash | | 4. Data Layer | ✅ GREEN | No pending migrations | | 5. API Stability | ✅ GREEN | Added endpoint only (backward compatible) | | 6. Security Gate | ✅ GREEN | No secrets found | | 7. Rollback Plan | ✅ GREEN | Plan generated |

Overall Verdict: 🔴 RED — Deploy blocked. Blocking Issue: REDIS_URL missing from .env.production. Add it before deploying. Template values found: REDIS_URL=your-redis-url-here.

Use Cases

• Running a pre-deploy validation before merging to main or production branch
• Catching environment misconfigurations that only manifest in production
• Generating a rollback plan before every deploy so the team is prepared
• Blocking deployments with known security vulnerabilities (hardcoded secrets, high CVEs)
• Creating a repeatable deploy checklist that scales across a team without requiring tribal knowledge

Known Limitations

The security gate uses regex pattern matching and may produce false positives on test data containing fake credentials. The API stability analysis works best with Express/FastAPI route definitions — custom routing frameworks may not be detected. Database migration analysis requires detecting the migration framework from directory structure, which may miss custom migration tools.

Tags: devops deployment security validation ci-cd production-safety rollback

Version: 1.0.0