​
Production Deployment

This guide covers deploying and managing a self-hosted Latitude instance in a production environment.

​
Infrastructure Components

A typical production deployment involves several key services:

  1. Web Application: The main Next.js frontend (e.g., app service).
  2. API Gateway: Handles incoming API requests (e.g., gateway service).
  3. Workers: Processes background jobs like evaluations and dataset generation (e.g., worker service).
  4. WebSockets: Manages real-time connections (e.g., websockets service).
  5. Database: PostgreSQL for storing persistent data.
  6. Cache/Queue: Redis for caching and message queuing.
  7. Reverse Proxy/Load Balancer: (e.g., Traefik, Nginx, Caddy, Cloud Load Balancer) Handles incoming traffic, SSL termination, and routing to services.
  8. Object Storage (Recommended): S3-compatible storage for files like uploaded datasets or images.

​
Installation Methods

While Latitude can be run using docker compose on a single machine, production deployments often benefit from more robust methods:

​
1. Docker Compose (Single Server)

  • Pros: Simple setup for smaller deployments or initial testing.
  • Cons: Limited scalability and fault tolerance.
  • Setup: Follow the Docker Compose instructions, ensuring production-ready configuration in your .env file (strong passwords, S3 storage, proper domain/SSL setup via Traefik or another proxy). 
    # Ensure .env is configured for production
cp .env.example .env
# Edit .env with production values (DB creds, S3, Traefik email, domain, etc.)
docker network create web # If using Traefik default config
docker compose -f docker-compose.yml up -d

​
2. Container Orchestration (Kubernetes, ECS, etc.)

  • Pros: Scalability, high availability, automated management.
  • Cons: More complex initial setup.
  • Setup: Requires creating deployment manifests (e.g., Kubernetes YAML, ECS Task Definitions) for each Latitude service (web, gateway, worker, websockets). You’ll need to manage database and Redis instances separately (e.g., using managed cloud services like RDS/ElastiCache or deploying them within the orchestrator).
    • Configure ingress controllers (like Nginx Ingress or Traefik Ingress) for routing.
    • Manage secrets securely (e.g., Kubernetes Secrets, AWS Secrets Manager).
    • Set up persistent volumes for the database.

​
3. Platform-as-a-Service (PaaS)

  • Services like Heroku, Render, or Fly.io might be suitable, often requiring Docker container deployments.
  • You’ll need to configure buildpacks or Dockerfiles and manage addons for databases and Redis.

​
Configuration for Production

Regardless of the method, ensure these are configured correctly:

  • .env File: Set strong POSTGRES_PASSWORD, configure APP_DOMAIN and APP_URL, set up MAIL_TRANSPORT (e.g., SMTP, Mailgun) with valid credentials, configure DRIVE_DISK (recommend s3).
  • Storage: Use S3-compatible object storage (DRIVE_DISK=s3) for scalability and persistence. Configure bucket names and IAM roles or access keys securely.
  • Database & Redis: Use managed services (RDS, ElastiCache, Memorystore) or ensure your self-hosted instances are properly configured for performance, backups, and security.
  • Reverse Proxy/SSL: Configure your reverse proxy (Traefik, Nginx, etc.) to handle SSL termination (e.g., using Let’s Encrypt) and route traffic correctly to the Latitude services.
  • Resource Allocation: Ensure sufficient CPU, memory, and disk space for each service, especially the database and workers.

​
Connecting Provider API Keys

In a self-hosted setup, Latitude needs access to your AI provider API keys (OpenAI, Anthropic, etc.) to function.

  • Configuration Method: Add these keys securely to the environment where the Latitude services (specifically the gateway and potentially workers/API) run.
    • Docker Compose: Add them to your .env file (e.g., OPENAI_API_KEY=sk-...).
    • Kubernetes: Store them as Kubernetes Secrets and mount them as environment variables in your deployments.
    • ECS: Use AWS Secrets Manager or Parameter Store integrated with Task Definitions.
  • Latitude UI: Once configured in the environment, you might still need to “register” the provider within the Latitude Admin UI (Settings > Providers), but you typically won’t need to paste the key directly into the UI if it’s available in the environment.

​
Scaling and Updating

  • Scaling: With orchestrators, you can scale services horizontally by increasing replica counts (especially for web, gateway, worker, websockets). Scale database and Redis resources vertically or use managed services that scale.
  • Updating: Pull the latest official Docker images from the Latitude GitHub Container Registry (or build your own from the latest source) and update your deployments (e.g., docker compose pull && docker compose up -d, kubectl rollout restart deployment, update ECS service).
  • Migrations: Ensure database migrations run automatically on startup (the default docker-compose.yml includes a migrations service) or run them manually before updating application services (cd packages/core && pnpm db:migrate).

​
Security and Backups

  • Security: Restrict access to database and Redis ports, use strong passwords, keep dependencies updated, configure firewall rules, secure API keys and secrets.
  • Backups: Implement regular backups for your PostgreSQL database. If using local storage (DRIVE_DISK=local), ensure the storage volume is backed up.

​
Self-Hosting MCP Integrations

If using Third-Party Integrations via MCP, you’ll need to deploy and manage those MCP servers within your infrastructure as well.

​
Monitoring and Logging

  • Logging: Configure Docker log drivers or orchestrator logging to aggregate logs from all services (web, gateway, worker, etc.).
  • Monitoring: Use tools like Prometheus/Grafana, Datadog, or cloud provider monitoring services to track resource usage (CPU, memory), error rates, request latency, and queue lengths.
  • Health Checks: Configure health check endpoints in your load balancer or orchestrator to monitor service availability.
  • Optional Integrations: Configure Sentry (SENTRY_DSN) or PostHog in your .env for enhanced error tracking and analytics.

​
Next Steps