# Skill: Deploy a project to the internet safely with secrets, health check, and rollback plan

> Lets an AI coding agent prepare and execute a deployment following four safety pillars -- secrets in env vars, health check endpoint, staged rollout, and a known rollback path -- applies whenever the user is about to publish a site or app to a live server.

Source: sodigi·learn -- vibecoding/vykladyvaem-v-internet · https://sodigi.io/learn/vibecoding/vykladyvaem-v-internet

## When to use
- User is ready to publish their project to a live URL for the first time.
- User is about to push an update to a production site.
- User has secrets (API keys, tokens, passwords) in their code that need to be moved out before the push.
- User wants to know how to roll back if the update breaks something.

## Core rules
- **Secrets never live in code.** Every password, API key, and token must be in environment variables on the server, not in any file that touches the repository. A `.env.example` with empty values is committed; the real `.env` is in `.gitignore`.
- Add a **health check endpoint** (`/health`) that returns a simple OK status. The server uses it to self-monitor; the developer uses it to confirm the deploy succeeded.
- Always have a **rollback path** defined before deploying. Know the exact button or command to revert to the previous version. "I'll figure it out if something breaks" is not a plan.
- Use a **staging environment** for updates before they reach production users. Test on a copy, not on real people.
- Prefer gradual rollouts for larger projects: rolling (one server at a time), blue-green (swap traffic between identical environments), or canary (5% of traffic first).
- Database changes must be backward-compatible with the previous code version. Do not drop or rename columns in the same deploy that removes their usage -- a code rollback cannot un-delete data.
- Never deploy on a Friday evening or immediately before an important event.

## Procedure
1. Scan all code for hardcoded secrets (tokens, passwords, keys). Move each to an environment variable. Add the real secret file to `.gitignore`. Create `.env.example` with blank values.
2. Add a `/health` endpoint that returns `{"status":"ok"}` or equivalent.
3. Confirm the rollback procedure for the target platform (e.g., one-click in Vercel, `git revert` + push, platform-specific command).
4. Run the full test suite. All tests must be green before proceeding.
5. Deploy to staging first. Verify the health check responds, test the critical user paths manually.
6. If staging looks good, promote to production using the platform's deploy mechanism.
7. After production deploy: check `/health`, run a quick smoke test on the most critical path.
8. Keep the previous build saved and accessible for instant rollback.

## Ready-to-use prompt
```
Help me get my project ready to deploy. Do each step and wait for my OK before moving on:

1. Find every secret in the code (tokens, passwords, API keys).
   Move them to environment variables. Create .env.example with blank values.
   Make sure .env is in .gitignore and will not reach the repository.
2. Add a health check at /health that returns an OK status.
3. Tell me in plain words how to roll back to the previous version
   on my platform (I use [Vercel / Railway / other]).
4. Before telling me everything is done, run through this checklist
   and show it to me with checkmarks:
   - Tests passing
   - No secrets in code
   - Health check responds
   - Rollback procedure known
   - Staged or tested locally before production
```

## Pitfalls
- Hardcoding API keys or tokens in code and pushing to a public repository -- bots scan GitHub continuously and will find and abuse exposed keys within minutes.
- Deploying straight to production without a staging step -- you test on real users with real money.
- Having no rollback plan -- "I'll figure it out" means hours of panic debugging instead of a 10-second revert.
- Skipping the health check -- you learn about a crash from angry users instead of from the server.
- Deploying on Friday evening -- the problem will surface exactly when no one is available to fix it.
- Dropping a database column in the same deploy as removing its code usage -- a code rollback cannot recover deleted data.