Skip to main content
In a BYOC (bring your own cloud) deployment, you run Lerian products inside your own AWS, GCP, or on-prem infrastructure and own the data and the runtime. Each service is configured through environment variables, and most of them are service-specific. This page covers the universal backbone — the variables that behave the same way across Lerian Go services — so you can set the deployment-wide knobs once and then reach for each product’s own page for the rest.
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.
For a production BYOC deployment, set DEPLOYMENT_MODE=byoc, connect every datastore over TLS, and leave ALLOW_INSECURE_TLS unset (false). The local defaults ship plaintext connections and are not safe for production.

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 at GET /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 sets STREAMING_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 use PLUGIN_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.