1. Never commit sensitive keys to version control

   • Use .env.local for local development (already in .gitignore)
   • Use .env.example or .env.local.example for documentation with placeholder values

2. Use proper prefixes

   • NEXT_PUBLIC_* - For variables that can be exposed to the browser
   • All other variables - Server-side only, kept secret

3. Sensitive Variables (Keep Secret!)

   • SUPABASE_SERVICE_ROLE_KEY - Full admin access to your database
   • UPLOADTHING_TOKEN - API access to your file upload service
   • Any other API keys or tokens without NEXT_PUBLIC_ prefix

4. Public Variables (Safe to expose)

   • NEXT_PUBLIC_SUPABASE_URL - Your Supabase project URL
   • NEXT_PUBLIC_SUPABASE_ANON_KEY - Public anonymous key with RLS protection
   • NEXT_PUBLIC_SITE_URL - Your website URL

1. Copy .env.local.example to .env.local
2. Fill in your actual values
3. Never commit .env.local

1. Set runtime secrets with Wrangler (never commit them): bunx wrangler secret put <NAME> or bunx wrangler secret bulk <file.json>
2. Required keys: SUPABASE_SERVICE_ROLE_KEY, UPLOADTHING_TOKEN, OPENROUTER_API_KEY, NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, NEXT_PUBLIC_SITE_URL
3. Use your actual values, not placeholders

• .env.local is in .gitignore
• No real API keys in .env.example
• No console.log of sensitive tokens
• Server-side keys only used in server components/API routes
• Regular key rotation for production environments

1. Immediately rotate the exposed keys

   • Supabase: Project Settings > API > Regenerate keys
   • UploadThing: Dashboard > Regenerate API key

2. Update all environments

   • Local .env.local
   • Vercel environment variables
   • Any other deployments

3. Check for unauthorized usage

   • Review Supabase logs
   • Check UploadThing usage statistics

If you discover a security vulnerability, please email security@vibedev.id instead of using public issue trackers.