vibe-safe-deploy
Performs deployment with pre-flight checks, atomic replacement, post-deploy verification, provenance (proving the environment serves the exact commit you pushed), and automatic rollback. Use before an
Files1
View on GitHubSKILL.mdplugins/vibe-engineering/skills/vibe-safe-deploy/SKILL.md
GitHubvibe-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
Pre-flight checks — Run all items in checklist. Stop if any fail.
Backup current state:
cp -r current_deploy/ current_deploy.prev/ # or: docker tag app:current app:rollbackDeploy 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 -dHealth check (within 60s timeout):
- Service starts successfully
- Health endpoint returns 200
- Key functionality works (smoke test)
- No error spikes in logs
If health check fails → automatic rollback:
cp -r current_deploy.prev/ current_deploy/ # Restart services with previous versionVerify 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>)
- Bake the commit SHA into the build or image and serve it at a version endpoint (for example
Report status: success / failed / rolled-back
Output Format
Deployment Report
Status: SUCCESS / FAILED / ROLLED_BACK Version: [version or commit hash] · Served SHA: [value from version endpoint] Duration: [time]
| Step | Status | Duration |
|---|---|---|
| Pre-flight | ✓ | 5s |
| Backup | ✓ | 2s |
| Deploy | ✓ | 10s |
| Health check | ✓ | 15s |
Post-Deploy Verification
- Service running: ✓
- Health endpoint: 200 OK
- Log errors: 0 in last 60s