Skip to main content
CharleOS is deployed to Vercel with automatic deployments from GitHub. This page provides an overview of the deployment process.

Deployment Architecture

Environments

Deployment Process

Automatic Deployments

Every push to main triggers a deployment:
1

Push to GitHub

2

Vercel Detects Change

Webhook triggers Vercel build automatically
3

Build Process

  • Install npm dependencies
  • Run database migrations (postinstall script)
  • Build Next.js application
  • Generate static assets
4

Deploy

  • Upload to Vercel’s CDN
  • Update DNS to point to new deployment
  • Old deployment kept for 30 days (rollback)
5

Post-Deploy

  • Environment goes live
  • Vercel sends notification
  • Logs available in dashboard

Preview Deployments

Pull requests get automatic preview deployments:
  • URL: https://charle-os-git-{branch}-charle.vercel.app
  • Purpose: Test changes before merging
  • Database: Uses DEV branch (safe to experiment)
  • Auto-cleanup: Deleted after PR merges

Build Configuration

package.json Scripts

Build process:
  1. npm install - Install dependencies
  2. postinstall hook runs → drizzle-kit migrate - Apply database migrations
  3. npm run build - Build Next.js app

Environment Variables

Production environment variables are set in Vercel dashboard: Required for build:
  • DATABASE_URL - Production database connection
  • BETTER_AUTH_SECRET - Auth encryption key
  • BETTER_AUTH_URL - https://charle.agency
  • GOOGLE_CLIENT_ID - Google OAuth credentials
  • GOOGLE_CLIENT_SECRET
Runtime variables:
  • All integration API keys (Pusher, Resend, Algolia, etc.)
  • Feature flags
  • Service URLs
Environment variables are encrypted at rest and only decrypted during build/runtime.

Database Migrations

Migrations run automatically during deployment:
How it works:
  1. Vercel installs dependencies
  2. postinstall hook triggers
  3. Drizzle applies pending migrations from drizzle/ folder
  4. If migrations fail, deployment fails (safe!)
  5. App starts with updated schema
Always test migrations locally before deploying. Failed migrations will prevent deployment.

Rollback

If a deployment has issues:

Option 1: Rollback in Vercel Dashboard

  1. Go to Vercel Dashboard
  2. Click “Deployments”
  3. Find previous working deployment
  4. Click ”⋯” → “Promote to Production”

Option 2: Revert Git Commit

Option 3: Redeploy Previous Commit

Monitoring

Vercel Analytics

Built-in analytics show:
  • Page views
  • Load times
  • Core Web Vitals
  • Top pages
Access: Vercel Dashboard → Analytics

Sentry Error Tracking

Production errors are tracked in Sentry:
  • Runtime errors
  • API failures
  • Performance issues
  • User context
Access: Sentry Dashboard

Logs

View deployment logs in Vercel: Build logs:
  • Show build output
  • Database migration results
  • Warnings and errors
Runtime logs:
  • API route logs
  • Server component logs
  • Edge function logs
Access: Vercel Dashboard → Deployments → Select deployment → Logs

Performance Optimization

Caching Strategy

Vercel automatically caches:
  • Static assets (images, CSS, JS)
  • Server Components (ISR)
  • API routes with Cache-Control headers

Edge Functions

API routes run on Vercel’s Edge Network:
  • Global: Deployed to 90+ edge locations
  • Fast: Sub-100ms response times
  • Scalable: Auto-scales to demand

Image Optimization

Next.js Image component uses Vercel’s optimization:
  • Automatic format conversion (WebP/AVIF)
  • Responsive sizing
  • Lazy loading
  • CDN caching

Security

  • All traffic encrypted with TLS 1.3
  • Automatic SSL certificate management
  • HTTP → HTTPS redirect
  • Encrypted at rest
  • Only decrypted during build/runtime
  • Never exposed in logs or UI
  • Vercel’s Edge Network provides DDoS mitigation
  • Automatic rate limiting
  • IP blocking for suspicious traffic

Troubleshooting

Build Failures

Error: “Build failed” Common causes:
  1. TypeScript errors
  2. Failed database migration
  3. Missing environment variables
  4. Dependency installation failure
Fix:
  1. Check build logs in Vercel dashboard
  2. Run npm run build locally to reproduce
  3. Fix errors and push again

Runtime Errors

Error: “Application error” / 500 Internal Server Error Fix:
  1. Check Sentry for error details
  2. View runtime logs in Vercel
  3. Verify environment variables are set
  4. Check database connection

Migration Failures

Error: “Migration failed” Fix:
  1. Test migration locally: npm run db:migrate
  2. Check migration SQL for syntax errors
  3. Verify database schema compatibility
  4. If needed, create fix-forward migration

Best Practices

Always build and test locally:
Test changes in preview before merging:
  1. Create PR
  2. Wait for Vercel preview deployment
  3. Test preview URL
  4. Merge when confirmed working
Watch for issues after deploying:
  • Check Vercel Analytics for traffic
  • Monitor Sentry for errors
  • Verify key user flows work
  • Check database migrations succeeded
Regular dependency updates:

Deployment Checklist

Before deploying to production:
  • All tests passing (unit + E2E)
  • TypeScript compiles without errors
  • Database migrations tested locally
  • Environment variables configured
  • Breaking changes documented
  • Rollback plan prepared
  • Monitoring/alerts configured

Vercel Deployment

Vercel-specific configuration

CI/CD Pipeline

Automated testing and deployment

Database Migrations

Managing schema changes

Environment Variables

Configuration reference