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. 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. MULTI_TENANCY_ENABLED activa la multi-tenancy (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
Estas variables definen los endpoints y las credenciales para la conexión con BTG. También definen 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. Autentica las llamadas internas entre los pods de worker y de API con una clave de API. Ambas claves 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. Si activas la multi-tenancy, 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.
