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 of these 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.

These set the deployment-wide default. An organization can override any of them from Organization Settings → Branding, which also accepts uploaded favicon and font files rather than URLs. A field the organization leaves empty falls back to the variable below, and then to the Rhesis default, so a multi-tenant deployment can set a house style here and let individual organizations depart from it.

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.

Custom font

When only BRAND_FONT_FAMILY is set, the font is loaded from Google Fonts. Add BRAND_FONT_BASE_URL for deployments that cannot reach Google (air-gapped, on-prem) or prefer to serve the files themselves. Name the .ttf files \{slug\}-\{weight\}.ttf (e.g. inria-sans-300.ttf, inria-sans-400.ttf, inria-sans-700.ttf).

An organization can override both variables for its members from the settings page, choosing either a Google Fonts family or its own uploaded files. Uploaded files are served from the configured object storage (STORAGE_SERVICE_URI) through the app, so no font host needs to be reachable from the browser; a Google family is loaded by the visitor’s browser and needs outbound access to fonts.googleapis.com.

What to upload

For organization branding set from the settings page rather than these variables:

The favicon is scaled down to the browser tab and up to 92 px in onboarding, so anything under 192x192 looks soft; the settings page warns when an uploaded icon is smaller than that or not square, but still accepts it. Uploads are checked to be real images, not just files with an image content type.

The font family field suggests names from the Google Fonts catalogue, fetched from Google and cached for a day; a deployment that cannot reach Google gets no suggestions and the field accepts any name. A Google family is checked against Google when you save, so a typo is rejected rather than silently falling back.

Uploaded fonts need only the weights you have. The app’s intermediate weights (500, 600, 800) are remapped onto 400 and 700, and the browser derives any missing weight from the nearest one it was given. The family name must match the name inside the font files.

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

Data retention

Two scheduled sweeps hard-delete rows past a retention window: one for job and activity_log rows, one for trace (span) rows. Both are off by default, and both run from celery beat — with no beat process against the backend, enabling either has no effect.

The trace sweep reads its window from each organization’s resolved plan. Self-hosted deployments have no usage limits, so every organization resolves to unlimited retention and the sweep deletes nothing until TRACE_RETENTION_DAYS supplies a window. Set it to put the whole deployment on one.

Advanced

Rarely changed; the defaults are correct for most deployments.

Cloud-only variables

Usage quota enforcement — per-organization resource limits (test executions, tracing spans, model tokens, etc.). Self-hosted deployments have no usage limits; the usage page still shows what the instance spent.

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, REQUIREMENTS, METRICS, and EXPERIMENTS.

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