| license | Apache-2.0 |
| name | vercel-deployment |
| description | Deploy Next.js applications to Vercel with proper configuration. Use when setting up deployment, configuring environment variables, edge functions, or troubleshooting builds. Activates for deployment issues, environment setup, and Vercel configuration. |
| allowed-tools | Read,Write,Edit,Bash(npm:*,npx:*,vercel:*) |
| category | DevOps & Infrastructure |
| tags | ["devops","automation","web","react"] |
Vercel Deployment
Deploy and configure Next.js applications on Vercel with expert-level decision-making for database selection, environment configuration, and production readiness.
DECISION POINTS
Database Selection Decision Tree
DECISION: What database should I use?
├── Development/Prototyping (< 1000 users expected)
│ ├── No external dependencies needed → SQLite (local file)
│ └── Need live data sharing → Turso (SQLite edge)
│
├── Production (> 1000 users, team collaboration)
│ ├── Simple schema, global edge performance → Turso
│ ├── Complex queries, existing Postgres knowledge → Vercel Postgres
│ ├── MySQL ecosystem, PlanetScale branching → PlanetScale
│ └── Self-managed, specific requirements → External Postgres/MySQL
│
└── High Scale (> 100k users)
├── Global read performance critical → Turso + caching
├── Complex analytics, reporting → Vercel Postgres
└── Cost optimization priority → External managed database
Environment Variable Scope Decision
DECISION: Where should this environment variable be set?
├── Contains secrets (API keys, database passwords)
│ ├── Used in build process → Build-time env var
│ └── Used at runtime → Runtime env var (Vercel Dashboard only)
│
├── Client-side access needed
│ ├── Public data (API endpoints) → NEXT_PUBLIC_ prefix
│ └── Should be server-only → Regular env var (no prefix)
│
└── Environment-specific values
├── Same across all environments → All scopes (Production + Preview + Development)
├── Different per environment → Separate values per scope
└── Preview testing only → Preview scope only
Build Failure Triage Decision
DECISION: Build failing - what's the root cause?
├── Build timeout (>10min Hobby, >45min Pro)
│ ├── Large bundle size → Analyze bundle, enable splitting
│ ├── Slow dependencies → Cache node_modules, optimize installs
│ └── Complex build step → Split into multiple functions
│
├── Memory errors (OOM)
│ ├── Build process → Reduce concurrent processes
│ └── Runtime → Increase function memory allocation
│
├── Environment variables missing
│ ├── Build-time vars → Set in Vercel project settings
│ └── Runtime vars → Check function logs, verify scope
│
└── Dependency issues
├── Version conflicts → Lock to specific versions
└── Missing peer deps → Install explicitly
FAILURE MODES
| Anti-Pattern | Detection Rule | Symptom | Diagnosis | Fix |
|---|
| Env Var Leakage | Client bundle contains server secrets | API keys visible in browser devtools | Used server env var without server-side check | Prefix with NEXT_PUBLIC_ only for public data, verify server-only vars |
| Build Timeout Spiral | Build time >15min, getting worse | Builds fail intermittently with timeout | Inefficient build process, growing dependencies | Enable build cache, analyze bundle size, split large operations |
| Edge Function Bloat | Edge function >5KB, slow cold starts | Preview deployments slow to respond | Imported server-only libraries in edge runtime | Move to serverless functions, use edge-compatible libraries only |
| Database Connection Pool Exhaustion | "too many connections" errors in production | 500 errors during traffic spikes | Each serverless function creates new connection | Implement connection pooling, use database proxy |
| Preview Environment Pollution | Production data appears in preview deployments | Test data mixed with real user data | Same database URL for preview and production | Separate DATABASE_URL for preview scope, use staging databases |
WORKED EXAMPLES
Example: Deploying Chat App with Turso Database
Situation: Deploy Next.js chat application with SQLite database to production
Expert Decision Process:
-
Database Selection (Decision Tree Navigation):
- Production app (>1000 users expected) ✓
- Simple schema (users, messages, sessions) → Turso selected
- Global performance important for real-time chat ✓
-
Environment Variable Configuration:
TURSO_DATABASE_URL=libsql://app-prod.turso.io
TURSO_AUTH_TOKEN=eyJ... (production token)
SESSION_SECRET=prod-32-char-secret
TURSO_DATABASE_URL=libsql://app-staging.turso.io
TURSO_AUTH_TOKEN=eyJ... (staging token)
SESSION_SECRET=preview-32-char-secret
-
Build Configuration:
{
"buildCommand": "npm run build && npm run db:push",
"regions": ["iad1", "fra1"],
"functions": {
"src/app/api/chat/route.ts": {
"maxDuration": 30
}
}
}
-
Validation Steps Taken:
- Test database connectivity:
npm run db:test-connection
- Verify environment variable scoping in preview
- Check build output size <50MB
- Validate edge function compatibility
Novice would miss: Setting different database URLs for preview vs production, optimizing regions for chat performance, longer timeout for AI endpoints.
Expert catches: Environment separation, performance implications of database location, build optimization for chat features.
QUALITY GATES
Deploy only when ALL conditions are met:
NOT-FOR BOUNDARIES
DO NOT use this skill for:
- Static site deployments without server features → Use [static-site-generation] instead
- Non-Next.js frameworks (Nuxt, SvelteKit) → Use [generic-vercel-deployment] instead
- Docker container deployments → Use [containerized-deployment] instead
- Multi-service applications requiring orchestration → Use [docker-compose-deployment] instead
Delegate to other skills:
- Database schema design → Use [database-design] skill
- API rate limiting implementation → Use [api-security] skill
- Performance optimization beyond deployment → Use [web-performance] skill
- CI/CD pipeline setup → Use [github-actions] skill