Nas tabelas abaixo, a coluna Padrão / Obrigatória mostra o valor padrão; um qualificador em negrito (por exemplo Obrigatória) marca variáveis que você deve definir.
— significa que não há padrão. 🔒 marca um segredo — injete-o no momento do deploy a partir do seu secret store, nunca faça commit dele. Esta página lista apenas nomes de variáveis e comportamento; ela não imprime nenhum valor de segredo.Este rail não monta a API de administração do systemplane. Ele usa o formato de datastore compartilhado
POSTGRES_* — consulte Datastores.Servidor e porta
O serviço escuta no endereço emSERVER_ADDRESS (padrão :8080). As probes de liveness, readiness e version se vinculam a essa mesma porta. A multi-tenancy é alternada com MULTI_TENANCY_ENABLED (note a grafia MULTI_TENANCY_; a conexão do Tenant Manager usa as variáveis compartilhadas MULTI_TENANT_*). Consulte Multi-tenancy e Portas de rede padrão.
Integração com a BTG
Endpoints e credenciais para a conexão com a BTG, além dos intervalos de refresh em segundo plano para o access token da BTG e as credenciais sincronizadas.Criptografia de credenciais e chaves de API internas
O rail criptografa as credenciais armazenadas em repouso e autentica chamadas internas (worker-to-API) com uma chave de API. Ambas suportam um slot_PREVIOUS para que você rotacione o valor ativo sem downtime.
Vínculo com o ledger Midaz
Reconciliação
Dispatch de webhook e idempotência
Migrações
Saúde e prontidão
O rail expõeGET /health (liveness) e GET /readyz (readiness) na porta principal. Quando a multi-tenancy está habilitada, ele adiciona uma probe por tenant protegida por auth em GET /readyz/tenant/{id}. Consulte Saúde e prontidão para o formato da resposta e o comportamento de startup/drain.
