In the tables below, the Default / Required column shows the default value. A bold qualifier marks a variable that you must set in the described context.
— means there is no default. 🔒 marks a secret — inject it at deployment time from your secret store and never commit it.How values.yaml and Systemplane work together
For initial deployment, customers provide configuration through the Helm chart values.yaml delivered with the release. After initialization, runtime keys are managed through Systemplane.
The chart turns values into pod environment variables:
Each domain has a dedicated Systemplane component. The flow is:
1
Render the release
Helm creates each component’s ConfigMap and references its Secret. The Deployment loads both with
envFrom when the pod starts.2
Initialize runtime configuration
The Systemplane component reads mapped environment variables and applies a seed only while the stored value still equals the registered default. An existing administrative override is not overwritten.
3
Consume the configuration
Domain APIs and workers read the Systemplane store. Each key definition determines whether it supports runtime updates or requires a restart.
4
Change the correct source
For bootstrap variables, update
values.yaml, run the upgrade, and roll out the component. After initialization, change runtime keys through Systemplane; changing values.yaml alone does not replace a stored override.- Direct bootstrap environment variables:
APPLICATION_NAME,SERVER_ADDRESS,DATABASE_URL,SYSTEMPLANE_POSTGRES_DSN,SYSTEMPLANE_SECRET_MASTER_KEY,VALKEY_URL,LICENSE_KEY,ORGANIZATION_IDS,SWAGGER_ENABLED,RABBITMQ_ENABLED,RABBITMQ_URI, andSTREAMING_*. - Also used as Systemplane seeds:
DEPLOYMENT_MODE,REQUEST_TIMEOUT_SEC,PLUGIN_AUTH_*,ORGANIZATION_ID,ISPB,ADAPTER_BASE_URL,MIDAZ_*,CRM_*,DICT_*,COB_*,SPI_*,KEY_CACHE_TTL_SEC, andVSYNC_*.
Set seeds in the Systemplane block that owns the domain, not in the API or worker block. Sensitive keys remain marked with
🔒 in the tables below.
All three blocks also receive the shared
DEPLOYMENT_MODE, REQUEST_TIMEOUT_SEC, and PLUGIN_AUTH_* seeds.
Pix Lerian does not expose catalog discovery. Use this page as the supported-key reference, and see Systemplane for the authorization and runtime update model.
Server and deployment mode
Each component receivesSERVER_ADDRESS from <component>.configmap.SERVER_ADDRESS; the value must match <component>.service.port in the same values.yaml. Liveness and readiness probes use that port. See Server and Health and readiness.
Persistence and runtime configuration
SPI, DICT, COB, and the adapter maintain separate stores. Do not reuse the same logical database across domains.Identity values, URLs, and credentials declared on configuration components are used as first-initialization seeds only. After a key exists in the runtime store, restarting the service does not overwrite the value. Make later changes through the authenticated configuration plane.
Institution identity
Midaz and CRM
SPI uses Midaz for accounting. SPI and DICT use CRM to validate accounts and holders in flows that require this information.Cross-domain integrations
The URLs below point to deployed Pix Lerian components. They configure communication between SPI, DICT, COB, and the adapter without changing the contract consumed by the client application.DICT reconciliation (VSync)
The VSync worker reconciles the persisted DICT database with the regulatory source. RabbitMQ transport is enabled by default; when active, it requires a valid URI.Streaming and observability
CloudEvents publishing from SPI, DICT, and COB uses theSTREAMING_* family and remains disabled by default. When STREAMING_ENABLED=true, STREAMING_BROKERS is required. If you set STREAMING_CLOUDEVENTS_SOURCE, the only accepted value is plugin-br-pix-lerian. See Streaming and outbox and Observability for the remaining broker, TLS, SASL, and OpenTelemetry parameters.
Bootstrap configuration source
The delivered Helm chartvalues.yaml is the deployment bootstrap source. Keep it aligned with the chart version and preserve component-block and variable names. Inject secrets from the secret store and never store plaintext credentials in the repository. After seeding, use Systemplane to change runtime keys.
Health and readiness
Configure probes through<component>.livenessProbe.path and <component>.readinessProbe.path in values.yaml. Default paths vary by component; do not assume unprefixed /health and /readyz paths.
The liveness probe checks whether the process is alive. The readiness probe checks whether required dependencies and configuration allow the component to receive traffic. Do not route traffic to a component until its readiness probe succeeds.
