Nas tabelas abaixo, a coluna Padrão / Obrigatória mostra o valor padrão. Um qualificador em negrito marca uma variável que você deve definir no contexto descrito.
— significa que não há padrão. 🔒 marca um segredo — injete-o no momento do deploy a partir do seu secret store e nunca faça commit dele.Como o values.yaml e o Systemplane se relacionam
Na implantação inicial, o cliente fornece a configuração pelo values.yaml do Helm chart entregue. Depois da inicialização, as chaves de runtime passam a ser administradas pelo Systemplane.
O chart transforma os values em variáveis de ambiente do pod:
Cada domínio possui um componente dedicado de Systemplane. O fluxo é:
1
Renderize o release
O Helm cria o ConfigMap e referencia o Secret de cada componente. O Deployment carrega ambos com
envFrom quando o pod inicia.2
Inicialize a configuração de runtime
O componente do Systemplane lê as envs mapeadas e aplica um seed apenas quando o valor armazenado ainda corresponde ao padrão registrado. Um override administrativo existente não é sobrescrito.
3
Consuma a configuração
APIs e workers do domínio leem o store do Systemplane. A definição de cada chave determina se ela aceita atualização em runtime ou se exige restart.
4
Altere a fonte correta
Para envs de bootstrap, altere o
values.yaml, execute o upgrade e faça o rollout do componente. Depois da inicialização, altere as chaves de runtime pelo Systemplane; mudar somente o values.yaml não substitui um override já gravado.- Env direta de bootstrap:
APPLICATION_NAME,SERVER_ADDRESS,DATABASE_URL,SYSTEMPLANE_POSTGRES_DSN,SYSTEMPLANE_SECRET_MASTER_KEY,VALKEY_URL,LICENSE_KEY,ORGANIZATION_IDS,SWAGGER_ENABLED,RABBITMQ_ENABLED,RABBITMQ_URIeSTREAMING_*. - Também usadas como seed do Systemplane:
DEPLOYMENT_MODE,REQUEST_TIMEOUT_SEC,PLUGIN_AUTH_*,ORGANIZATION_ID,ISPB,ADAPTER_BASE_URL,MIDAZ_*,CRM_*,DICT_*,COB_*,SPI_*,KEY_CACHE_TTL_SECeVSYNC_*.
Defina os seeds no bloco do Systemplane que pertence ao domínio, e não no bloco da API ou do worker. As chaves sensíveis continuam marcadas com
🔒 nas tabelas abaixo.
Os três blocos também recebem os seeds compartilhados
DEPLOYMENT_MODE, REQUEST_TIMEOUT_SEC e PLUGIN_AUTH_*.
O Pix Lerian não expõe descoberta de catálogo. Use esta página como referência das chaves suportadas e consulte Systemplane para o modelo de autorização e atualização de runtime.
Servidor e modo de implantação
Cada componente recebeSERVER_ADDRESS por <componente>.configmap.SERVER_ADDRESS; o valor deve coincidir com <componente>.service.port no mesmo values.yaml. As probes de liveness e readiness usam essa porta. Consulte Servidor e Saúde e prontidão.
Persistência e configuração de runtime
SPI, DICT, COB e o adaptador mantêm stores separados. Não reutilize o mesmo banco lógico entre domínios.Valores de identidade, URLs e credenciais declarados nos componentes de configuração são usados como seed apenas na primeira inicialização. Depois que uma chave existe no store de runtime, reiniciar o serviço não sobrescreve o valor. Alterações posteriores devem ser feitas pelo plano autenticado de configuração.
Identidade da instituição
Midaz e CRM
O SPI usa o Midaz para contabilização. SPI e DICT usam o CRM para validar contas e titulares nos fluxos que exigem essa informação.Integrações entre os domínios
As URLs abaixo apontam para os componentes implantados do próprio Pix Lerian. Elas definem a comunicação entre SPI, DICT, COB e o adaptador, sem alterar o contrato consumido pela aplicação cliente.Reconciliação do DICT (VSync)
O worker VSync reconcilia a base persistida do DICT com a fonte regulatória. O transporte RabbitMQ é habilitado por padrão; quando ativo, exige uma URI válida.Streaming e observabilidade
A publicação de CloudEvents do SPI, DICT e COB usa a famíliaSTREAMING_* e permanece desativada por padrão. Quando STREAMING_ENABLED=true, STREAMING_BROKERS é obrigatória. Se você definir STREAMING_CLOUDEVENTS_SOURCE, o único valor aceito é plugin-br-pix-lerian. Consulte Streaming e outbox e Observabilidade para os demais parâmetros de broker, TLS, SASL e OpenTelemetry.
Fonte de configuração de bootstrap
Ovalues.yaml do Helm chart entregue é a fonte de bootstrap da implantação. Mantenha o arquivo alinhado à versão do chart e preserve os nomes dos blocos e das variáveis. Injete segredos a partir do secret store e não armazene credenciais em texto aberto no repositório. Após o seed, use o Systemplane para alterar chaves de runtime.
Saúde e readiness
Configure as probes pelos campos<componente>.livenessProbe.path e <componente>.readinessProbe.path do values.yaml. Os paths padrão variam por componente; não assuma /health e /readyz sem prefixo.
A liveness probe verifica se o processo está ativo. A readiness probe verifica se as dependências e as configurações obrigatórias permitem receber tráfego. Não direcione tráfego para um componente enquanto a readiness probe não retornar sucesso.