Configuración y despliegue

Lender es un único servicio en Go, empaquetado como contenedor y configurado por completo mediante variables de entorno. Esta página es la referencia del operador: como qué se ejecuta, de qué depende, los ajustes que importan y cómo se comportan el multi-tenancy y el enrutamiento al ledger.

El contenedor

Lender se construye desde un Dockerfile multietapa (un builder Go Alpine que produce un binario estático, copiado a un runtime distroless nonroot) y escucha en el puerto 8080. Se entrega como una imagen de contenedor que despliegas en tu clúster de con las herramientas de ciclo de vida estándar de la plataforma. Esta página no supone ningún empaquetado particular más allá de la imagen. Sondas operativas:

Endpoint	Propósito
`GET /health`	Liveness.
`GET /readyz`	Readiness de las dependencias.
`GET /version`	Metadatos de build y de versión.

Dependencias

Dependencia	Rol
PostgreSQL 17	Almacén de datos principal, con capacidad primario/réplica y aislamiento de un schema por tenant en modo multi-tenant.
Valkey 8 (compatible con Redis)	Cache, rate limiting y el cache de credenciales M2M.
RabbitMQ	Transporte de mensajería separado para los subsistemas que no son de ciclo de vida; no es el transporte del catálogo de hechos de ciclo de vida de Lender.
RedPanda	Backbone de streaming compatible con Kafka para los hechos de ciclo de vida, publicados a través de la biblioteca de streaming y el outbox transaccional de Lerian.
Midaz	El de partida doble, al que se llega a través del SDK oficial. Lender se autentica mediante Access Manager con credenciales máquina a máquina (M2M) por tenant, recuperadas del backend de custodia configurado — AWS Secrets Manager de forma predeterminada o HashiCorp Vault KV v2 cuando se selecciona — y cacheadas en Valkey.
Caradhras	Backend de identidad detrás de Access Manager. La autorización de rutas corre a través de la biblioteca de auth de Lerian.
Systemplane	Plano de configuración en tiempo de ejecución, montado bajo `/api/v1/systemplane`.

Superficie de configuración

La configuración se maneja por completo desde el entorno. Las claves de abajo moldean el comportamiento. No son la lista completa.

Grupo	Clave	Qué controla
App	`ENV_NAME`, `LOG_LEVEL`, `DEPLOYMENT_MODE`, `SERVER_ADDRESS`	Nombre del entorno, verbosidad de los logs, modo de despliegue y dirección de escucha.
Tenancy	`MULTI_TENANT_ENABLED`, `DEFAULT_TENANT_ID`	Cambia entre los modos single-tenant y multi-tenant, y el tenant que se usa en single-tenant.
Tenancy (MT)	`MULTI_TENANT_MAX_TENANT_POOLS`, `MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLD`	Techo del pool de conexiones por tenant y punto de disparo del circuit breaker.
Postgres	`POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_NAME`, `POSTGRES_SSLMODE`	Conexión a la base de datos principal. Los directorios de migración están fijos en la imagen del servicio, no son configurables.
Cache	`REDIS_HOST`, `REDIS_PASSWORD`, `M2M_CREDENTIAL_CACHE_TTL_SEC`	Conexión a Valkey y cuánto tiempo se cachean las credenciales M2M.
Mensajería	`RABBITMQ_ENABLED`, `RABBITMQ_HOST`, `OUTBOX_DISPATCH_INTERVAL_SEC`	Vía de mensajería separada de RabbitMQ y cadencia del dispatcher. Estas variables no configuran los temas de eventos de ciclo de vida. El outbox de PostgreSQL siempre se inicializa; no tiene bandera de habilitación.
Streaming	`STREAMING_ENABLED`, `STREAMING_BROKERS`, `STREAMING_TLS_ENABLED`, `STREAMING_TLS_CA_CERT`	Toggle del streaming de eventos de ciclo de vida, direcciones de brokers compatibles con Kafka, TLS y un certificado CA PEM opcional codificado en base64 para confiar en brokers privados. Un base64 inválido o un contenido decodificado que no es PEM impide el arranque.
Auth	`PLUGIN_AUTH_ENABLED`, `AUTH_M2M_INVERSION_ENABLED`	Autorización de rutas y la compuerta obligatoria de inversión M2M para BYOC.
Seguridad del proxy	`TLS_TERMINATED_UPSTREAM`, `TRUST_PROXY_ENABLED`, `TRUSTED_PROXIES`	Terminación TLS upstream y la lista restrictiva de proxies de confianza que exige en despliegues endurecidos.
Consignado	`CONSIGNADO_ENABLED`	El valor predeterminado es `true`. Solo controla el manejo entrante heredado de `consignado.averbacao.rejected`: la ruta de contratação, el firmante de CCB y el consumidor de averbação confirmada están retirados. Cuando lo deshabilitas, mantén también `CONSUMER_CONSIGNADO_AVERBACAO_REJECTED_ENABLED` desactivado; el arranque rechaza esa configuración contradictoria. La administración de cartera de los contratos existentes y las vías de reemplazo de contabilización y de pago se configuran de forma independiente. Consulta Consignado privado.
Custodia M2M del ledger	`M2M_SECRETS_BACKEND`, `M2M_VAULT_MOUNT`, `AWS_REGION`	Backend de custodia de credenciales (AWS de forma predeterminada o HashiCorp Vault KV v2), su mount KV y la región de AWS cuando se selecciona AWS.
Cuentas del ledger	`MIDAZ_LEDGER_ACCOUNT_PROVISIONING_ENABLED`	El valor predeterminado es `true`. Antes de que un relay contabilice, Lender confirma que existen los alias de cuenta no externa del perfil contable; deshabilítalo solo cuando aprovisionas por adelantado el plan de cuentas. Nunca crea activos.
Observabilidad	`ENABLE_TELEMETRY`, `OTEL_EXPORTER_OTLP_ENDPOINT`	Toggle de telemetría y endpoint del colector OTLP.
Límites	`RATE_LIMIT_ENABLED`	Rate limiting de las solicitudes. Siempre activo cuando `ENV_NAME=production`.
Docs	`SWAGGER_ENABLED`	Sirve el documento OpenAPI y la interfaz de la referencia de API. Siempre desactivado cuando `ENV_NAME=production`.

Modos multi-tenant

Lender corre en uno de dos modos:

Single-tenant: un tenant (DEFAULT_TENANT_ID), un schema de base de datos, y una organización del ledger y un ledger definidos en tiempo de construcción que se usan como destino predeterminado de los asientos.
Multi-tenant (MULTI_TENANT_ENABLED=true): persistencia con un schema por tenant, un pool de clientes de Midaz por tenant, y eventos y asientos con ámbito de tenant. En este modo no hay un ledger predeterminado por entorno: el destino del ledger viene por transacción desde el perfil contable del producto.

Asiento en el ledger y enrutamiento que falla cerrado

Una contabilización llega al ledger a través de una intención de asiento durable y un relay asíncrono. La vía completa está en Lender en la plataforma. El enrutamiento falla cerrado. Un asiento se contabiliza en la organización del ledger y el ledger que se resuelven desde el perfil contable. En modo single-tenant, un asiento que no resuelve ningún destino de perfil recurre al predeterminado del entorno. Si ninguno de los dos resuelve un destino no vacío, Lender rechaza contabilizar en lugar de asentar en un ledger vacío o equivocado. Por eso, en modo multi-tenant, un producto sin perfil contable no puede contabilizar. Esa salvaguarda es intencional.

Próximos pasos

Lender en la plataforma

La vía de los asientos, el catálogo de eventos y el aislamiento por tenant en detalle.

Resumen

Primeros pasos

Conceptos

Guías

Integración

Operaciones

Configuración y despliegue

El contenedor

Dependencias

Superficie de configuración

Modos multi-tenant

Asiento en el ledger y enrutamiento que falla cerrado

Próximos pasos

Lender en la plataforma

​El contenedor

​Dependencias

​Superficie de configuración

​Modos multi-tenant

​Asiento en el ledger y enrutamiento que falla cerrado

​Próximos pasos

Lender en la plataforma

El contenedor

Dependencias

Superficie de configuración

Modos multi-tenant

Asiento en el ledger y enrutamiento que falla cerrado

Próximos pasos