deployment-procedures — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited deployment-procedures (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill is about how to reason through a release, not a script to run. Two deployments are never quite the same, so the goal is to internalize the principles and translate them to whatever platform is in front of you. Whenever a step appears, ask why it exists before you perform it.
What you're shipping decides the platform, and the platform decides the mechanics.
What kind of thing is this?
├─ Static site / JAMstack ........ Vercel · Netlify · Cloudflare Pages
├─ Ordinary web app
│ ├─ want it managed .......... Railway · Render · Fly.io
│ └─ want full control ........ a VPS with PM2 or Docker
├─ Many small services ........... a container orchestrator
└─ Event-driven / functions ...... edge runtimes · LambdaEach one releases differently:
| Platform | How a release happens |
|---|---|
| Vercel / Netlify | Push to git, it builds and ships |
| Railway / Render | Git push or a CLI command |
| VPS + PM2 | SSH in and run the steps yourself |
| Docker | Push an image, then orchestrate it |
| Kubernetes | kubectl apply the manifests |
Group your pre-flight checks into four buckets, and don't proceed until all four are green:
| Bucket | The question it answers |
|---|---|
| Code health | Do tests pass, is it linted, did someone review it? |
| Build | Does the production build succeed cleanly? |
| Environment | Are env vars present and secrets current? |
| Safety net | Is there a backup and a written rollback path? |
PREPARE → re-check code, build, and config
SNAPSHOT → capture the current state so you can return to it
SHIP → push the change with dashboards open
INSPECT → health check, scan logs, walk a key flow
SETTLE → looks good? lock it in. trouble? roll back.| Phase | The principle |
|---|---|
| Prepare | Untested code never goes out |
| Snapshot | No backup means no way back |
| Ship | Stay and watch; don't push and leave |
| Inspect | Assume nothing works until you've seen it work |
| Settle | Keep a finger on the rollback trigger |
| Signal | Why it matters |
|---|---|
| Health endpoint | Confirms the process is actually up |
| Error stream | Catches anything new that just appeared |
| Critical flows | Proves the features users depend on still work |
| Latency | Shows response times haven't regressed |
| What you see | What to do |
|---|---|
| Service is down | Roll back now |
| Errors flooding in | Roll back |
| Latency more than halved | Lean toward rolling back |
| Small, contained glitch | Fix forward if it's quick |
| Platform | Rollback move |
|---|---|
| Vercel / Netlify | Re-promote the previous deploy |
| Railway / Render | Roll back from the dashboard |
| VPS + PM2 | Restore the snapshot, restart |
| Docker | Re-deploy the prior image tag |
| Kubernetes | kubectl rollout undo |
| Look at | Usual suspects |
|---|---|
| Logs | Exceptions, stack traces |
| Resources | Disk full, out of memory |
| Network | DNS, firewall, routing |
| Dependencies | Database, third-party APIs |
| Don't | Do instead |
|---|---|
| Ship Friday afternoon | Ship early in the week |
| Hurry the rollout | Move through the phases |
| Skip the staging pass | Always rehearse first |
| Deploy with no backup | Snapshot before you ship |
| Push and walk away | Stay on it 15+ minutes |
| Bundle many changes | One change at a time |
Before you hit go:
Every release carries risk. You shrink that risk through preparation, never through speed.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.