To secure a Bolt.new + Vercel stack, you need to: (1) move all secrets and API keys from code to Vercel environment variables, (2) add security headers via vercel.json including X-Frame-Options and CSP, (3) ensure API routes require authentication before processing requests, and (4) configure preview deployments to use test databases instead of production data. This blueprint covers deployment-specific security for Vercel hosting.
TL;DR
Deploying Bolt exports to Vercel requires security configuration beyond defaults. Key tasks: move all secrets to Vercel environment variables, add security headers via vercel.json, secure API routes with authentication, and configure different environments for preview vs production.
Part 1: Vercel Environment Variables
# Database
DATABASE_URL="your-connection-string"
# Public (client-accessible)
NEXT_PUBLIC_SUPABASE_URL="https://xxx.supabase.co"
NEXT_PUBLIC_SUPABASE_ANON_KEY="eyJ..."
# Private (server-only)
SUPABASE_SERVICE_ROLE_KEY="eyJ..."
JWT_SECRET="your-secret"
Check exported code: Bolt may have hardcoded values. Search for API keys and secrets before deploying.
Part 2: Vercel Security Headers
{
"headers": [
{
"source": "/(.*)",
"headers": [
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" }
]
}
]
}
Security Checklist
Vercel Deployment Checklist
All secrets in Vercel environment variables
No hardcoded credentials in code
Security headers in vercel.json
API routes require authentication
Preview environment uses test database
.env files in .gitignore
Alternative Stacks to Consider
**Bolt.new + Netlify**
Alternative deployment platform
**Bolt.new + Railway**
Container-based deployment
**Bolt.new + Supabase + Vercel**
Complete stack security
Can preview deployments access production data?
By default, previews use the same environment variables. Scope sensitive variables to "Production" only in Vercel dashboard.