Skip to main content

Metabind CMS Deployment Guide

Environments

Development

Production

Deployment Process

Development Deployment (Automatic)

  1. Create feature branch from develop
  2. Make changes and test locally
  3. Create PR to develop
  4. After review, merge PR
  5. Automatic deployment to dev.metabind.ai

Production Deployment (Manual Approval)

  1. Ensure all changes are tested on dev environment
  2. Create PR from develop to main
  3. Review changes thoroughly
  4. Merge PR to main
  5. GitHub Actions will request manual approval
  6. Go to Actions tab → Click on the workflow run → Review and approve
  7. Deployment proceeds to www.metabind.ai

Release Creation (Optional)

For formal releases with version tags:
  1. Go to Actions → “Create Release” workflow
  2. Click “Run workflow”
  3. Enter version (e.g., v1.0.0)
  4. Check “pre-release” if applicable
  5. This creates a release branch and draft release

Infrastructure

AWS Resources

  • S3 Buckets:
    • Dev: metabind-frontend-dev
    • Prod: metabind-frontend-prod
  • CloudFront Distributions:
    • Dev: E37V5H2J99LGBJ (dev.metabind.ai)
    • Prod: EAMI96CJSLZDO (www.metabind.ai)
  • Route53: Managed DNS for both domains

Environment Variables

Environment-specific configs are set during build:
  • VITE_API_URL: API endpoint
  • VITE_WS_URL: WebSocket endpoint
  • VITE_CDN_URL: CDN endpoint
  • VITE_ENV: Environment name
  • VITE_USER_POOL_ID: Cognito User Pool ID
  • VITE_USER_POOL_CLIENT_ID: Cognito User Pool Client ID

Local Development

Setup

# Install dependencies
pnpm install

# Copy environment file
cp .env.example .env.local

# Start development server
pnpm run dev

Building Locally

# Build for development
pnpm run build-app

# Build for production (with prod env vars)
VITE_API_URL=https://api.metabind.ai pnpm run build-app

Manual Deployment

# Deploy to dev (requires AWS credentials)
pnpm run deploy:dev:local

# Deploy to prod (requires AWS credentials)
pnpm run deploy:prod

Security

GitHub Secrets Required

  • AWS_ACCESS_KEY_ID: AWS deployment credentials
  • AWS_SECRET_ACCESS_KEY: AWS deployment credentials

Production Environment Protection

  • Requires manual approval from designated reviewers
  • Configure in: Settings → Environments → production

Rollback Procedure

Quick Rollback

  1. Go to GitHub Actions
  2. Find the last successful deployment
  3. Click “Re-run all jobs”
  4. Approve deployment

S3 Versioning Rollback

  1. Go to AWS S3 Console
  2. Navigate to the production bucket
  3. Use “Show versions” to see previous deployments
  4. Restore previous version if needed

Monitoring

CloudFront Cache

  • Invalidations happen automatically on deploy
  • Manual invalidation: aws cloudfront create-invalidation --distribution-id EAMI96CJSLZDO --paths '/*'

Deployment Status

  • Check GitHub Actions for deployment logs
  • CloudFront distribution status in AWS Console
  • Test endpoints after deployment

Team Workflow

Feature Development

  1. Create feature branch from develop
  2. Implement and test locally
  3. Create PR to develop
  4. Code review by team
  5. Merge triggers auto-deploy to dev

Production Release

  1. Test thoroughly on dev environment
  2. Create release PR from develop to main
  3. Team reviews release notes
  4. Merge PR (doesn’t auto-deploy)
  5. Designated approver triggers production deployment
  6. Verify production deployment

Important Notes

  1. Never commit .env.local or any file with secrets
  2. Always test on dev before releasing to prod
  3. CloudFront cache takes ~5-10 minutes to fully propagate
  4. DNS changes can take up to 48 hours (though usually much faster)
  5. Production deployments should be done during low-traffic periods

Troubleshooting

Build Failures

  • Check Node.js version (should be 20)
  • Verify PNPM version matches workflows
  • Clear node_modules and pnpm store

Deployment Failures

  • Check AWS credentials are valid
  • Verify S3 bucket permissions
  • Check CloudFront distribution status

Cache Issues

  • Force CloudFront invalidation
  • Clear browser cache
  • Check cache headers in S3
For additional help, check the GitHub Actions logs or contact the team lead.