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. You own the data and the runtime. You configure each service 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. Set the deployment-wide knobs once, then use each product’s own page for the rest. For Pix Lerian v1.0.0, BYOC configuration supports its delivered components and mock-adapter integration/testing lane. It does not make the native SPI messaging connector available or make the mock adapter a production rail.
These variables form 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. The /readyz response reports its value.
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_*). Plugins and rails use the flat POSTGRES_* shape above. In multi-tenant mode, the service ignores static datastore credentials and resolves connections 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. The service also 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 most services. The exception is the native rails (for example SPI and SILOC), which do not expose STREAMING_ENABLED at all. Streaming on those rails has no disabled mode: STREAMING_BROKERS is mandatory, and the service refuses to start when that value is absent or invalid. Check each product’s page for its contract.
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 (Caradhras-backed). The authentication toggle, its variable name, and its default differ by service. Most plugins and products use PLUGIN_AUTH_ENABLED (default false, off). 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. 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 form 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

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.