This is the shared backbone, not the full list. Variable prefixes differ slightly between services (for example, a service with separate onboarding and transaction databases namespaces them), and every service adds its own keys. See Per-product variables for the exhaustive lists.
Deployment mode and TLS
DEPLOYMENT_MODE sets how strictly the service enforces TLS on its infrastructure connections, and its value is echoed in the /readyz response.
Server
Some services expose a numeric
SERVER_PORT instead of, or alongside, SERVER_ADDRESS. Worker components without a primary HTTP API expose a dedicated health port (for example HEALTH_PORT or WORKER_SERVER_PORT). See Default network ports and Health and readiness.Datastores
Every service that persists state connects to one or more datastores. The variable prefix depends on the store — and, in some services, on the logical database. The table below shows the common shape; consult each product’s page for the exact names.Not every service uses every store, and prefixes vary: core products often namespace connections per logical database (for example
DB_ONBOARDING_*, DB_TRANSACTION_*, MONGO_CRM_*), while plugins and rails use the flat POSTGRES_* shape above. In multi-tenant mode, static datastore credentials are ignored — connections are resolved per tenant (see below).Multi-tenancy
Multi-tenancy is off by default. When you enable it, every datastore connection switches from static configuration to per-tenant resolution through Tenant Manager, and the service adds a per-tenant readiness probe atGET /readyz/tenant/{id}.
Additional per-tenant pool sizing, circuit-breaker, and cache-TTL knobs (
MULTI_TENANT_MAX_TENANT_POOLS, MULTI_TENANT_CIRCUIT_BREAKER_*, MULTI_TENANT_CACHE_TTL_SEC, and others) exist per service. See the per-product pages.Runtime configuration
When enabled, the service exposes an authenticated plane for reading and writing runtime configuration. See Systemplane for the API, namespaces, and required permissions.
Streaming and outbox
The event-publication path (a lib-streaming producer backed by a transactional outbox) is off by default in every service except the Fetcher worker, which setsSTREAMING_ENABLED=true to emit job-completion events.
STREAMING_SASL_* and STREAMING_TLS_* secure the broker connection — set them when your broker requires authentication or TLS.Service discovery
Consul service discovery is off by default. When enabled, the service registers itself and resolves peers through Consul instead of static addresses.Some services use legacy aliases (
SD_ADVERTISE_*, CONSUL_ADDR) for the same behavior.Observability
Telemetry is push-based (OTLP). Some services additionally expose a/metrics endpoint for Prometheus scraping — see Health and readiness.
Plugin authentication
Lerian services can authenticate protected routes — including the systemplane admin API — through Access Manager (Casdoor-backed). The authentication toggle, its variable name, and its default differ by service: most plugins and products usePLUGIN_AUTH_ENABLED (default false, off), while native rails such as SILOC and SPB use AUTH_ENABLED (default true, on — required in production and SaaS) paired with AUTH_ADDRESS. Always enable authentication in production, and check each product or rail’s own environment-variables page for the authoritative toggle name, its default, and the routes it protects.
Per-product variables
The variables above are the shared baseline. Each product adds its own — datastore prefixes, integration URLs, worker tuning, and feature toggles. Use the per-product pages for the full, current list:Midaz
Tracer
Reporter
Flowker
Lender
Fetcher
The exhaustive, per-service variable list ships in each service’s
.env.example file. Treat it as the source of truth for a specific release, and never commit real secret values into it.
