Deployment Procedures
Run a principle-driven production release with the right platform choice, pre-flight checks, rollback thinking, and post-deploy verification instead of copying one-size-fits-all bash scripts.
Overview
Deployment Procedures is an agent skill most often used in Ship (also Operate) that teaches safe production deployment principles—platform choice, pre-flight verification, rollback, and post-release checks—without relyin
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill deployment-proceduresWhat is this skill?
- Platform selection decision tree (static/JAMstack, simple web app, microservices, serverless) with Vercel, Railway, Dock
- Four pre-deployment verification categories: code quality, build, config/secrets, and operational readiness
- Teaches WHY and adaptation per platform—explicitly not memorize-and-paste deploy scripts
- Covers rollback strategies and safe release verification mindset for critical-risk production changes
- Maps deployment method by platform (git push auto-deploy vs SSH/PM2 vs image push vs kubectl apply)
- 4 pre-deployment verification categories
- Platform decision tree with 4 top-level deployment shapes
Adoption & trust: 644 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are ready to push to production but every platform uses different steps, and copying a random deploy script hides missing tests, config, or rollback plan.
Who is it for?
Solo builders shipping SaaS, APIs, or side projects who want structured deploy reasoning across Vercel, Railway, VPS, Docker, or Kubernetes.
Skip if: Teams that already have locked, audited CI/CD pipelines and only need the agent to run a fixed internal playbook verbatim.
When should I use this skill?
You are preparing a production release, choosing a deployment platform, or need rollback and verification principles—not a generic script.
What do I get? / Deliverables
You leave with a platform-matched release checklist, explicit verification categories satisfied, and a rollback mindset before traffic hits the new build.
- Platform-aligned deploy plan with verification steps
- Pre-flight checklist mapped to the four categories
- Documented rollback triggers and verification signals
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill centers on releasing to production safely; the same decision framework also applies when hardening Operate workflows after go-live. Launch subphase matches cutover to production, deploy method selection, and release verification—not local test-only work.
Where it fits
Pick Railway vs Fly vs VPS before the first paying-user deploy.
Confirm secrets and env parity in the four verification categories before cutover.
Plan rollback when a Docker image push causes regressions in production.
Define what to verify immediately after release when error rates spike.
How it compares
Principle-first release workflow skill—not a Terraform pack or a host-specific MCP integration.
Common Questions / FAQ
Who is deployment-procedures for?
Indie and solo developers using Claude Code, Cursor, or Codex who own deploys end-to-end and need judgment calls, not a single bash recipe.
When should I use deployment-procedures?
Use it in Ship when choosing a host and running pre-deploy checks; in Operate when planning rollbacks or verifying a recurring release; anytime risk is production-critical.
Is deployment-procedures safe to install?
It guides thinking and does not execute deploys by itself; review the Security Audits panel on this Prism page and treat production credentials and shell access as your responsibility.
SKILL.md
READMESKILL.md - Deployment Procedures
# Deployment Procedures > Deployment principles and decision-making for safe production releases. > **Learn to THINK, not memorize scripts.** --- ## ⚠️ How to Use This Skill This skill teaches **deployment principles**, not bash scripts to copy. - Every deployment is unique - Understand the WHY behind each step - Adapt procedures to your platform --- ## 1. Platform Selection ### Decision Tree ``` What are you deploying? │ ├── Static site / JAMstack │ └── Vercel, Netlify, Cloudflare Pages │ ├── Simple web app │ ├── Managed → Railway, Render, Fly.io │ └── Control → VPS + PM2/Docker │ ├── Microservices │ └── Container orchestration │ └── Serverless └── Edge functions, Lambda ``` ### Each Platform Has Different Procedures | Platform | Deployment Method | |----------|------------------| | **Vercel/Netlify** | Git push, auto-deploy | | **Railway/Render** | Git push or CLI | | **VPS + PM2** | SSH + manual steps | | **Docker** | Image push + orchestration | | **Kubernetes** | kubectl apply | --- ## 2. Pre-Deployment Principles ### The 4 Verification Categories | Category | What to Check | |----------|--------------| | **Code Quality** | Tests passing, linting clean, reviewed | | **Build** | Production build works, no warnings | | **Environment** | Env vars set, secrets current | | **Safety** | Backup done, rollback plan ready | ### Pre-Deployment Checklist - [ ] All tests passing - [ ] Code reviewed and approved - [ ] Production build successful - [ ] Environment variables verified - [ ] Database migrations ready (if any) - [ ] Rollback plan documented - [ ] Team notified - [ ] Monitoring ready --- ## 3. Deployment Workflow Principles ### The 5-Phase Process ``` 1. PREPARE └── Verify code, build, env vars 2. BACKUP └── Save current state before changing 3. DEPLOY └── Execute with monitoring open 4. VERIFY └── Health check, logs, key flows 5. CONFIRM or ROLLBACK └── All good? Confirm. Issues? Rollback. ``` ### Phase Principles | Phase | Principle | |-------|-----------| | **Prepare** | Never deploy untested code | | **Backup** | Can't rollback without backup | | **Deploy** | Watch it happen, don't walk away | | **Verify** | Trust but verify | | **Confirm** | Have rollback trigger ready | --- ## 4. Post-Deployment Verification ### What to Verify | Check | Why | |-------|-----| | **Health endpoint** | Service is running | | **Error logs** | No new errors | | **Key user flows** | Critical features work | | **Performance** | Response times acceptable | ### Verification Window - **First 5 minutes**: Active monitoring - **15 minutes**: Confirm stable - **1 hour**: Final verification - **Next day**: Review metrics --- ## 5. Rollback Principles ### When to Rollback | Symptom | Action | |---------|--------| | Service down | Rollback immediately | | Critical errors | Rollback | | Performance >50% degraded | Consider rollback | | Minor issues | Fix forward if quick | ### Rollback Strategy by Platform | Platform | Rollback Method | |----------|----------------| | **Vercel/Netlify** | Redeploy previous commit | | **Railway/Render** | Rollback in dashboard | | **VPS + PM2** | Restore backup, restart | | **Docker** | Previous image tag | | **K8s** | kubectl rollout undo | ### Rollback Principles 1. **Speed over perfection**: Rollback first, debug later 2. **Don't compound errors**: One rollback, not multiple changes 3. **Communicate**: Tell team what happened 4. **Post-mortem**: Understand why after stable --- ## 6. Zero-Downtime Deployment ### Strategies | Strategy | How It Works | |----------|--------------| | **Rolling** | Replace instances one by one | | **Blue-Green** | Switch traffic between environments | | **Canary*