Environment Variables

Complete reference for configuring a self-hosted Rhesis deployment. For a guided walkthrough of the essentials, see the Docker Compose guide.

Set variables in the .env.docker file you pass to Docker Compose:

docker compose --env-file .env.docker up -d

Empty values are treated as unset — the built-in default applies. In .env.example, commented lines show the default each variable falls back to, so you only uncomment a line to override it.

Required

These four secrets have no default; the stack refuses to start if any is unset.

Public URLs and ports

Ports are the host bind ports and are independent of the URLs — behind a reverse proxy the published port and the public URL usually differ.

Branding

Replace the Rhesis colours, icon and product name with your own. All four are read at request time, so the same image serves every deployment — no rebuild, and no NEXT_PUBLIC_ counterpart. Each is independent; set only the ones you need.

Light and dark shades are derived from each colour, and button label text switches between white and near-black to stay readable — a pale brand colour does not need extra configuration. A malformed value is ignored with a warning in the frontend logs and the Rhesis default applies, so a typo cannot break a deployment.

One difference between the two colours: the built-in secondary uses a different hue for its hover (orange to yellow) and near-black for secondary.dark. A configured BRAND_SECONDARY_COLOR gets a plain lighten/darken ramp instead, so secondary buttons brighten on hover within your own hue rather than shifting to another colour.

Setting BRAND_PRODUCT_NAME also drops the Rhesis tagline from the page description and stops the sign-in wordmark linking to rhesis.ai.

Three things keep their Rhesis identity on purpose: chart palettes, which need distinguishable hues rather than tints of one colour; the sign-in page’s background artwork; and the Documentation, Blog and GitHub links in the sign-in header.

On Kubernetes, set these through the chart instead — see Kubernetes (Helm).

Database

Defaults point at the built-in postgres container. Set these to use your own database (see Database). DB_NAME and APP_DB_USER are fixed and cannot be changed — SQL scripts reference them by name, so your database and role must use exactly these values.

Redis and Celery

Defaults point at the built-in redis container. Set these to use an external Redis.

AI models

Generation, evaluation, execution, and embeddings use Rhesis-hosted models by default, which require a RHESIS_API_KEY (get one at app.rhesis.ai ). To use your own provider, set that provider’s key and point the matching DEFAULT_*_MODEL at it.

Provider keys, read at runtime when a DEFAULT_*_MODEL targets that provider:

Supported model-provider prefixes: openai, gemini, azure, anthropic, groq, mistral, together_ai, perplexity, replicate, openrouter, cohere, ollama. Supported embedding prefixes: rhesis, openai, gemini, vertex_ai.

Authentication and OAuth

Without OAuth credentials, only email/password authentication is available.

SMTP and email

Email (notifications, invitations) is disabled until SMTP_HOST is set.

Object storage

Enterprise features

Only used when the Enterprise package is installed (see Enterprise Features). Each feature stays disabled until its secret is set and valid.

Telemetry

See Telemetry System Documentation for what is collected.

Logging and tuning

Advanced

Rarely changed; the defaults are correct for most deployments.

Cloud-only variables

Onboarding and lifecycle emails — the hosted SendGrid drip campaign and welcome flow.

Hosted UI enrichment — frontend NEXT_PUBLIC_* values baked in at build time. When unset the UI simply omits the extra media, so self-hosting is unaffected.

The empty-state pair exists for each of TESTS, PROJECTS, TEST_SETS, TEST_RUNS, ENDPOINTS, BEHAVIORS, METRICS, and EXPERIMENTS.

Enterprise and GCP-hosted infrastructure — specific to Rhesis’s managed environment.