Environment Variables

Environment variables take precedence over the YAML file — the standard pattern for injecting secrets via a K8s Secret / systemd EnvironmentFile / Docker --env-file without putting them in the config file itself.

Variable	Default	Description
CONFIG_FILE	see note below	Path to YAML config
HOST	0.0.0.0	Bind address
PORT	8000	Bind port
LOG_LEVEL	info	Uvicorn log level
RELOAD	false	Hot-reload (dev only)
MONGODB_URI	—	Overrides storage.mongodb.uri (K8s Secret injection)
JWT_SECRET	—	Overrides jwt.secret — set this in any multi-replica/production deployment
TWO_FACTOR_SECRET_KEY	—	Overrides two_factor.secret_encryption_key — set this in any multi-replica/production deployment
LLM_CREDENTIAL_KEY	—	Overrides llm.credential_encryption_key — set this in any multi-replica/production deployment. Applies to platform-only deployments too: this package encrypts SSO connection client secrets under it
AUTH_API_KEY	—	Overrides auth.api_key, the bootstrap credential. Set this. Unset does not mean “no bootstrap key” — it means authentication is disabled and every caller becomes an anonymous superadmin (see the caution below)
DEFAULT_ADMIN_EMAIL	—	Overrides auth.default_admin_email. Read once, at first boot, to seed the initial superadmin; ignored afterwards
DEFAULT_ADMIN_PASSWORD	—	Overrides auth.default_admin_password. Same first-boot-only rule; must be at least 8 characters or seeding is skipped
DEPLOYMENT_MODE	self_hosted	Overrides deployment.mode (self_hosted or cloud) — identifies which deployment this process is, not a per-org setting. See Billing / quota enforcement
SERVER_COOKIE_DOMAIN	—	Seeds (does not override) server.cookie_domain, first boot only. server is platform-managed, so this is a one-time bootstrap for a split-domain deployment; PATCH /admin/settings always wins afterwards

CONFIG_FILE has no single default

It depends on which entry point you start, since each ships its own example config: configs/opentremor-platform-local.yaml for a platform-only process, configs/opentremor-core-local.yaml for core run directly, and — for this workspace’s docker stacks — the shared configs/opentremor-local.yaml at the workspace root, set explicitly by both compose files.

The three encryption keys fail silently

JWT_SECRET, TWO_FACTOR_SECRET_KEY and LLM_CREDENTIAL_KEY each back a config field that otherwise defaults to a fresh random value per process. Nothing errors at startup when they’re unset — the damage surfaces later, as logged-out users after a restart and as SSO connection secrets, stored LLM credentials and enrolled TOTP secrets that can no longer be decrypted by anyone.

AUTH_API_KEY unset disables authentication entirely

auth.api_key defaults to None, and None does not mean “no bootstrap key is available” — it means the API has no authentication at all. resolve_auth short-circuits every request, authenticated or not, to a superadmin owner of the default organization; dashboard sessions collapse to the same identity. That is deliberate and useful for the local quickstart and the test suite, and catastrophic anywhere reachable.

It is reachable by omission alone: forget the variable, ship a config file with no auth section, and the server starts perfectly happily with an open API. Two things guard it — the server logs a prominent AUTHENTICATION IS DISABLED warning at startup whenever it boots in this state, and docker-compose.prod.yaml requires AUTH_API_KEY through a ${VAR:?} substitution so the production stack refuses to start without one. Neither helps a hand-rolled deployment: if you run the server yourself, setting this is on you.

Unlike the three keys above, this one is safe to rotate — nothing is encrypted under it, so changing it only invalidates the old key.

See Full Reference for what each corresponding YAML field controls.

No GITHUB_* variables

Earlier versions read GITHUB_APP_ID/GITHUB_PRIVATE_KEY/GITHUB_WEBHOOK_SECRET here. github is now one of the sections managed exclusively through the platform admin panel — set the platform’s GitHub App via PATCH /admin/settings once the server is up instead, same as logging/registration/server. See Platform settings.

---

Validation

Configuration is validated by Pydantic at startup. Invalid values (wrong type, missing required fields, out-of-range numbers) raise a clear error before the server binds to any port.