Skip to main content

​
Requirements

Before deploying, ensure the following are available:
  • Node.js 18+
  • pnpm 10+
  • PostgreSQL
  • Redis (required by BullMQ queues — there is no in-memory fallback)
  • Docker (required if using the Runner)
  • Writable directories for logs and backups

​
Deployment modes

The server process serves both the /api routes and the compiled frontend static assets from ./public. This is the simplest deployment topology.One container or process handles everything. No separate runner process is required unless you want isolated review execution.

​
Required environment variables

VariableDescription
DATABASE_URLPostgreSQL connection string
BETTER_AUTH_SECRETAuthentication secret (32+ characters)
VariableDescription
APP_URLPublic URL of the application
APP_URLsAllowed origin URLs
BETTER_AUTH_URLURL used by Better Auth
PORTServer listen port (default: 3000)
HOSTNAMEServer listen hostname
REDIS_URLRedis connection string
AI_REVIEW_CONCURRENCYNumber of concurrent review jobs
WEBHOOK_BASE_URLBase URL for incoming webhooks
LOG_DIRDirectory for log files
LOG_LEVELLog verbosity level
LOG_RETENTION_DAYSHow many days to retain log files
BACKUP_DIRDirectory for backup files
AUTO_BACKUP_ENABLEDEnable automatic backups
BACKUP_RETENTION_DAYSHow many days to retain backups
METRICS_RETENTION_DAYSHow many days to retain metrics data

​
AI provider configuration

The currently active AI runtime is volcengine. For review and chat functionality in production, configure at minimum: 
VOLCENGINE_API_KEY=your-key
VOLCENGINE_ENDPOINT=your-endpoint
Other provider variables (OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_OPENAI_API_KEY, etc.) are accepted by the container but correspond to runtimes that are not currently active.

​
Build

1

Install dependencies

pnpm install --frozen-lockfile
2

Build all packages

pnpm build
This builds the environment package, the frontend, and the server. The frontend build output is copied into the server’s dist/public directory.To build individual packages:
# Server only
pnpm --filter server build

# Frontend only
pnpm --filter web build

​
Database migration

Always run the database migration before deploying a new version. Running migrations after deployment can result in the application starting against an incompatible schema.
pnpm --filter server db:migrate
Production migration best practices:
  • Validate the migration on a staging environment first
  • Confirm a valid backup exists before migrating the production database
  • Use a minimal-privilege database account for the application

​
Deploying with Docker Compose

1

Create your production env file

Copy and populate .env.production with your required environment variables.
2

Run the migration

pnpm --filter server db:migrate
3

Start the application

docker compose --env-file .env.production -f docker-compose.yml up -d
The container exposes port 3000 internally. The Docker Compose file maps it to host port 9000 by default:
ports:
  - "9000:3000"
4

Verify the service

curl http://localhost:9000/api/health

​
Static asset hosting

In production, the server serves frontend static files from the ./public directory relative to its working directory. If your build artifact distribution differs from the default build process, ensure the compiled frontend assets are placed where the server process can access them at runtime.

​
Upgrade procedure

1

Record the current commit SHA

git rev-parse HEAD
2

Validate on staging

Run the database migration and verify webhook behavior on a staging environment before touching production.
3

Verify runner registration

Confirm that runner registration, heartbeat reporting, and task pickup still work after the migration.
4

Deploy to production

Run the migration, then deploy the new container or process.

Build docs developers (and LLMs) love

Get started for freeTalk to us