Docker Compose

Deploy Rhesis on your own infrastructure with proper security, authentication, and production configuration.

Production Setup

The steps below are the recommended path for a production self-hosted deployment: you supply your own secrets, public URLs, and infrastructure, and run the stack directly with Docker Compose. (For a throwaway local instance, use the one-command Quick Start instead.)

# 1. Clone the repository
git clone https://github.com/rhesis-ai/rhesis.git
cd rhesis

# 2. Copy environment variables
cp .env.example .env.docker

# 3. Generate the four required secrets into .env.docker
#    (DB_ENCRYPTION_KEY, JWT_SECRET_KEY, NEXTAUTH_SECRET, SESSION_SECRET_KEY)
./rh secrets

# 4. Start all services
docker compose --env-file .env.docker up -d

Access the applications

• Frontend: http://localhost:3000 
• Backend API: http://localhost:8080/docs 

This starts a self-contained stack with a built-in Postgres and Redis. From here you can customize the deployment — for example, pointing at an external database, setting your public URLs, or enabling OAuth and email — as described in Environment Configuration below.

Environment Configuration

This section covers the variables you need to set for a production deployment. For the complete list — every variable, its default, and whether it is required — see the Environment Variables reference.

Required secrets

Four secrets are required and have no safe default; the stack refuses to start if any is unset. Generate them as shown in Production Setup (step 3) and set them in .env.docker.

Public URLs

Set FRONTEND_URL and API_BASE_URL to the public origins your users reach. When either starts with https://, the stack issues secure (HTTPS-only) cookies. FRONTEND_PORT and BACKEND_PORT are the host ports Docker publishes and are independent of these URLs — behind a reverse proxy the published port and the public URL usually differ.

FRONTEND_URL=https://app.example.com
API_BASE_URL=https://api.example.com

Database

By default the stack runs a built-in postgres container. To use your own PostgreSQL instead, set the variables below and grant the role read/write privileges on the database.

The database name and user are fixed — some scripts reference them by name — so when you provision your own database you must create it with exactly these names:

To use an external Redis, set BROKER_URL and CELERY_RESULT_BACKEND.

AI Models

Rhesis provides the models used for test generation, evaluation, multi-turn execution, and embeddings. By default the stack uses rhesis/rhesis-default for generation, evaluation, and execution, and rhesis/rhesis-embedding for embeddings. These models are hosted by Rhesis and require a RHESIS_API_KEY — without it, generation, execution, and Explorer embedding workflows will fail.

# Rhesis API key (get from https://app.rhesis.ai/)
RHESIS_API_KEY=your-actual-rhesis-api-key-here

To run against your own model provider instead, see the Environment Variables reference.

Optional configuration

The variables above get a deployment running. Everything else is optional — see the Environment Variables reference for the details:

• Configure an OAuth provider (Google or GitHub) for social login — Authentication and OAuth
• Configure email (SMTP) for notifications and invitations — SMTP and email
• Configure object storage for files (GCS or S3) — Object storage
• Tune the Celery worker for throughput — Logging and tuning

Enterprise Features

Enterprise Edition features are discovered at runtime through GET /features; the frontend hides gated UI until a feature appears there. Without the Enterprise package, Rhesis runs in Community mode and all three are unavailable.

Two features need their own secret — set it in .env.docker (see Enterprise features for how to generate each). The feature stays disabled until its secret is present and valid.

Telemetry & Privacy

For self-hosted deployments: Telemetry is ENABLED by default (opt-out).

To opt-out, add to your .env.docker file:

# Disable telemetry (opt-out)
OTEL_RHESIS_TELEMETRY_ENABLED=false

Details of exactly what is and isn’t collected, and how the data is used, are in the Telemetry System Documentation.

Management Commands

Service Management

# Start all services in detached mode
docker compose --env-file .env.docker up -d

# Start with logs visible
docker compose --env-file .env.docker up

# Stop all services
docker compose down

# Stop and remove volumes (WARNING: deletes all data)
docker compose down -v

# Restart all services
docker compose --env-file .env.docker restart

# Restart specific service
docker compose --env-file .env.docker restart backend

Monitoring and Logs

View logs:

# All services
docker compose logs

# Specific service
docker compose logs backend
docker compose logs frontend
docker compose logs worker

# Follow logs in real-time
docker compose logs -f backend

Check service status:

# View running containers and their status
docker compose ps

Building and Updates

Rebuild services:

# Rebuild all services
docker compose --env-file .env.docker build

# Rebuild specific service
docker compose --env-file .env.docker build backend

# Rebuild and restart
docker compose --env-file .env.docker up -d --build

Backup and Recovery

Database Backup

# Create database backup
docker exec rhesis-postgres pg_dump -U rhesis-user rhesis-db > backup.sql

# Restore from backup
docker exec -i rhesis-postgres psql -U rhesis-user -d rhesis-db < backup.sql

Full System Backup

# Stop services
docker compose down

# Backup volumes
docker run --rm -v rhesis_postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_backup.tar.gz -C /data .
docker run --rm -v rhesis_redis_data:/data -v $(pwd):/backup alpine tar czf /backup/redis_backup.tar.gz -C /data .

# Restart services
docker compose --env-file .env.docker up -d

System Requirements

Production Environment

For production deployment with real users:

Detailed Resource Breakdown