En las tablas siguientes, la columna Valor por defecto / Requerida muestra el valor por defecto; un calificador en negrita (por ejemplo Requerida) marca las variables que debes definir.
— significa que no hay valor por defecto. 🔒 marca un secreto: inyéctalo en el momento del despliegue desde tu almacén de secretos y nunca lo guardes en el repositorio. Esta página solo enumera los nombres de las variables y su comportamiento; no imprime ningún valor secreto.Este rail no monta la API de administración de systemplane. Usa la forma de almacén de datos compartida
POSTGRES_*; consulta Almacenes de datos.Servidor y puerto
El servicio escucha en la dirección deSERVER_ADDRESS (por defecto :8080). Las sondas de liveness, readiness y versión se enlazan a este mismo puerto. La multi-tenancy se activa con MULTI_TENANCY_ENABLED (fíjate en la grafía MULTI_TENANCY_; la conexión al Tenant Manager usa las variables compartidas MULTI_TENANT_*). Consulta Multi-tenancy y Puertos de red predeterminados.
Integración con BTG
Endpoints y credenciales para la conexión con BTG, más los intervalos de refresco en segundo plano del token de acceso de BTG y de las credenciales sincronizadas.Cifrado de credenciales y claves de API internas
El rail cifra las credenciales almacenadas en reposo y autentica las llamadas internas (worker a API) con una clave de API. Ambas admiten un slot_PREVIOUS para que puedas rotar el valor activo sin downtime.
Vínculo con el ledger Midaz
Reconciliación
Despacho de webhooks e idempotencia
Migraciones
Salud y readiness
El rail exponeGET /health (liveness) y GET /readyz (readiness) en el puerto principal. Cuando la multi-tenancy está habilitada, añade una sonda por tenant protegida por autenticación en GET /readyz/tenant/{id}. Consulta Salud y readiness para la forma de la respuesta y el comportamiento de arranque/drenaje.