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. Inyecta cada secreto en el momento del despliegue desde tu almacén de secretos. Nunca guardes un secreto 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. Sus variables de almacén de datos usan un prefijo
DB_* en lugar de la forma compartida POSTGRES_*. Consulta Almacenes de datos más abajo.Componentes y puertos
El componente API escucha enSERVER_PORT (por defecto 4014). SERVER_ADDRESS se deriva de él. Los workers de reconciliación, calendario y webhooks enlazan cada uno un WORKER_PORT para sus sondas de salud. Cada worker lleva sus propios ajustes de tuning —tamaños de lote, intervalos de sondeo, concurrencia y circuit breakers— en su archivo .env.example. Consulta Puertos de red predeterminados.
Integración con BTG y mTLS
Estas variables contienen las credenciales y los ajustes de TLS mutuo para la conexión con BTG.Almacenes de datos
Este rail usa un prefijoDB_* para los almacenes de datos, no la forma compartida POSTGRES_*. Se conecta a un PostgreSQL principal, una réplica de lectura separada, MongoDB y Redis.
Midaz, CRM y Fees
Webhooks internos y programación
La API y los workers intercambian eventos a través de un canal de webhooks interno. También ejecutan flujos Pix recurrentes y programados.Alcance de Pix y del ledger
Salud y readiness
Cada componente exponeGET /health (liveness) y GET /readyz (readiness) en su puerto. Consulta Salud y readiness para la forma de la respuesta y el comportamiento de arranque y drenaje.
