Production Deployment
Deploy CodePilot to production using Docker Compose or Railway.
This guide covers deploying CodePilot to a production environment.
Docker Compose Deployment
The simplest production deployment uses docker-compose.prod.yml:
Prepare Environment Files
Create production environment files with secure values:
# Generate secure secrets
openssl rand -hex 32 # For ENCRYPTION_SECRET
openssl rand -base64 32 # For token secretsConfigure .env, .env.api, .env.worker, and .env.web with production values. See Environment Variables for the full reference.
Run Database Migrations
pnpm --filter @repo/db run db:deploydb:deploy vs db:migrate
db:deploy applies pending migrations without prompts — suitable for CI/CD and production. db:migrate is for development and prompts for migration names.
Build and Start
docker compose -f docker-compose.prod.yml up -d --buildThis builds all service images and starts the full stack.
Verify
Check that all containers are running:
docker compose -f docker-compose.prod.yml ps| Service | Status | Port |
|---|---|---|
codepilot_postgres | healthy | 5432 |
codepilot_redis | healthy | 6379 |
codepilot_api | running | 8080 |
codepilot_worker | running | — |
codepilot_web | running | 3000 |
Railway Deployment
CodePilot can be deployed to Railway for managed hosting:
Create a Railway Project
Create a new project on Railway and link your GitHub repository.
Add Services
Add the following services to your Railway project:
- PostgreSQL (with pgvector plugin)
- Redis
- API (from
apps/api/Dockerfile) - Worker (from
apps/worker/Dockerfile) - Web (from
apps/web/Dockerfile)
Configure Environment Variables
Set environment variables for each service in the Railway dashboard. Use Railway's internal networking for service-to-service communication.
Deploy
Railway automatically builds and deploys when you push to the linked branch.
Production Checklist
- All environment variables configured with production values
- Secure secrets generated (not defaults)
- Database migrations applied
- Ollama accessible from containers
- GitHub App webhook URL pointing to production domain
- CORS configured for production frontend URL
- SSL/TLS configured for HTTPS
- Volumes configured for data persistence
- Health checks passing for all services
- Logging and monitoring configured
Ollama in Production
Ollama Hosting
Ollama must be accessible from your production containers. Options:
- Same server: Run Ollama on the host and access via
host.docker.internal:11434 - Separate server: Run Ollama on a GPU-equipped server and point
OLLAMA_URLto its address - Cloud GPU: Use a cloud GPU instance (e.g., AWS, GCP) running Ollama
Reverse Proxy
For production, place a reverse proxy (Nginx, Caddy, or Traefik) in front of the web and API services for:
- SSL/TLS termination
- Domain routing
- Rate limiting
- Gzip compression