vibe-safe-deploy

vibe-safe-deploy

Ship with confidence. Every deployment should be verifiable and reversible.

When to Use This Skill

• Deploying to staging or production environments
• Releasing a new version
• Deploying infrastructure changes

When NOT to Use This Skill

• Local development builds
• CI/CD that already handles these checks
• Deploying documentation (low risk)

Pre-Flight Checklist

Before deploying, verify:

• All tests pass (including integration tests)
• Linting is clean
• No uncommitted changes in working tree
• No secrets in the diff (grep -r 'API_KEY\|SECRET\|PASSWORD')
• Build succeeds
• Database migrations are reversible (if applicable)

Steps

1. Pre-flight checks — Run all items in checklist. Stop if any fail.

2. Backup current state:

   cp -r current_deploy/ current_deploy.prev/
   # or: docker tag app:current app:rollback
   

3. Deploy using atomic operations:

   # Use 'install' not 'cp' for atomic file replacement
   install -m 755 new_binary /path/to/binary
   # or: docker tag app:new app:current && docker-compose up -d
   

4. Health check (within 60s timeout):

   • Service starts successfully
   • Health endpoint returns 200
   • Key functionality works (smoke test)
   • No error spikes in logs

5. If health check fails → automatic rollback:

   cp -r current_deploy.prev/ current_deploy/
   # Restart services with previous version
   

6. Verify provenance. "Deploy succeeded" means a job finished, not that the new build is being served.

   • Bake the commit SHA into the build or image and serve it at a version endpoint (for example /version.txt)
   • After deploy, poll that endpoint until it returns the expected SHA; on timeout, fail and report the SHA it actually served
   • Keep environments separate: branch pushes deploy preview (behind auth, noindex), and only the main branch deploys production
   • Give the deploy credential the least privilege that works (for example a forced-command SSH key that accepts only <environment> <sha>)