> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuración y despliegue
> Cómo se empaqueta y se ejecuta Lender: la forma del contenedor, sus dependencias, una superficie curada de variables de entorno, los modos multi-tenant y la vía de asiento en el ledger.
export const GLedger = ({children}) =>
{children}
;
export const GKubernetes = ({children}) =>
{children}
;
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 Kubernetes con las [herramientas de ciclo de vida](/es/platform/lifecycle-management) 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 ledger de partida doble, al que se llega a través del SDK oficial. Lender se autentica mediante [Access Manager](/es/platform/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](/es/products/lender/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](/es/products/lender/lender-in-the-platform). 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
***
La vía de los asientos, el catálogo de eventos y el aislamiento por tenant en detalle.