$ man context-wiki/deployments-vercel

Deployment is making your local code changes live on the internet. Push to GitHub. Vercel picks it up. Builds the site. Deploys it. Done. The first time I pushed to main and saw Vercel build my site in 45 seconds, it felt like skipping straight to the good part. No FTP uploads. No manual file transfers. Just push the code and it is live. Three websites (shawnos.ai, thegtmos.ai, thecontentos.ai) all deploy from one push. That is not magic. That is just how modern deployment works.

PATTERN

Every branch gets its own preview URL. Push a feature branch to GitHub and Vercel generates a unique URL where you can see your changes before they go live. This is huge for testing. You can share the preview URL with a collaborator, check it on your phone, or just verify that your changes look right before merging to main. The workflow: create a branch, make changes, push the branch, check the preview URL, fix issues if needed, merge to main when it looks good, main auto-deploys to production. You never deploy broken code to production because you caught it in preview first.

PATTERN

Secrets live on Vercel, not in your code. API keys, database URLs, MCP tokens. You add them in the Vercel dashboard for each project. Your deployed site accesses them through process.env. They never appear in your repo, never get committed to Git, never show up in build logs. Locally, you create a .env file with the same variables. Add .env to .gitignore so it never gets committed. Vercel has its own copy for production. This separation means you can have different values for local development and production without any conflicts.

PRO TIP

I built the /deploy skill so I never have to remember the deployment steps. It stages all changed files. Generates a commit message from the diff. Commits. Pushes to GitHub. Waits for Vercel to start the build. Monitors build progress. Confirms all three sites are live with 200 status codes. Reports results. I type /deploy. Everything else happens automatically. Three websites from one push. Under a minute. This is the skill pattern applied to infrastructure. I could run the commands manually. But why? The skill is faster, more consistent, and catches errors I would miss. It also logs the deployment for the daily tracker.

ANTI-PATTERN

Deploys fail for three common reasons. Build errors: TypeScript complaints, missing imports, broken dependencies. Fix the error locally, push again. Environment variable issues: a variable exists locally but not on Vercel. Check the Vercel dashboard and add the missing variable. Dependency conflicts: your lock file is out of sync with your package.json. Delete node_modules, reinstall, push the updated lock file. The /deploy skill checks build status and reports failures with the relevant error. But if you skip the skill and push manually, check the Vercel dashboard for build logs. The error is always in the logs. Read them before guessing.