> ## 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. # Configuração e deploy > Como o Lender é empacotado e executado: o formato do container, as dependências dele, uma superfície selecionada de variáveis de ambiente, os modos multi-tenant e o caminho de lançamento no ledger. export const GLedger = ({children}) => {children} ; export const GKubernetes = ({children}) => {children} ; O Lender é um único serviço Go, empacotado como container e configurado inteiramente por variáveis de ambiente. Esta página é a referência do operador: como ele roda, do que ele depende, quais configurações importam e como o tenancy e o roteamento do ledger se comportam. ## O container *** O Lender é construído a partir de um Dockerfile multi-estágio (um builder Go Alpine que produz um binário estático, copiado para um runtime distroless nonroot) e escuta na porta `8080`. Ele é entregue como uma imagem de container da qual você faz o deploy no seu cluster Kubernetes com o [ferramental de ciclo de vida](/pt/platform/lifecycle-management) padrão da plataforma. Esta página não supõe nenhum empacotamento específico além da imagem. Probes operacionais: | Endpoint | Finalidade | | -------------- | ---------------------------- | | `GET /health` | Liveness. | | `GET /readyz` | Readiness das dependências. | | `GET /version` | Metadados de build e versão. | ## Dependências *** | Dependência | Papel | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **PostgreSQL 17** | Armazenamento de dados principal, com suporte a primário/réplica e isolamento com schema por tenant no modo multi-tenant. | | **Valkey 8** (compatível com Redis) | Cache, rate limiting e o cache de credenciais M2M. | | **RabbitMQ** | Transporte de mensageria separado para subsistemas fora do ciclo de vida; ele não é o transporte do catálogo de fatos de ciclo de vida do Lender. | | **RedPanda** | Backbone de streaming compatível com Kafka para fatos de ciclo de vida, publicados pela biblioteca de streaming da Lerian e pelo outbox transacional. | | **Midaz** | O ledger de partidas dobradas, alcançado pelo SDK oficial. O Lender se autentica pelo [Access Manager](/pt/platform/access-manager) com credenciais máquina a máquina (M2M) por tenant, buscadas no backend de custódia configurado — AWS Secrets Manager por padrão ou HashiCorp Vault KV v2 quando selecionado — e mantidas em cache no Valkey. | | **Caradhras** | Backend de identidade por trás do Access Manager. A autorização de rotas passa pela biblioteca de auth da Lerian. | | **Systemplane** | Plano de configuração em runtime, montado sob `/api/v1/systemplane`. | ## Superfície de configuração *** A configuração é inteiramente dirigida pelo ambiente. As chaves abaixo moldam o comportamento. Elas não são a lista completa. | Grupo | Chave | O que ela controla | | ---------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | App | `ENV_NAME`, `LOG_LEVEL`, `DEPLOYMENT_MODE`, `SERVER_ADDRESS` | Nome do ambiente, verbosidade do log, modo de deploy e endereço de escuta. | | Tenancy | `MULTI_TENANT_ENABLED`, `DEFAULT_TENANT_ID` | Alterna entre os modos single-tenant e multi-tenant, e o tenant usado no modo single-tenant. | | Tenancy (MT) | `MULTI_TENANT_MAX_TENANT_POOLS`, `MULTI_TENANT_CIRCUIT_BREAKER_THRESHOLD` | Teto do pool de conexões por tenant e ponto de disparo do circuit breaker. | | Postgres | `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_NAME`, `POSTGRES_SSLMODE` | Conexão com o banco de dados principal. Os diretórios de migração são fixos na imagem do serviço, não configuráveis. | | Cache | `REDIS_HOST`, `REDIS_PASSWORD`, `M2M_CREDENTIAL_CACHE_TTL_SEC` | Conexão com o Valkey e por quanto tempo as credenciais M2M ficam em cache. | | Mensageria | `RABBITMQ_ENABLED`, `RABBITMQ_HOST`, `OUTBOX_DISPATCH_INTERVAL_SEC` | Caminho separado de mensageria RabbitMQ e cadência do dispatcher. Essas variáveis não configuram os tópicos de eventos de ciclo de vida. O outbox no PostgreSQL é sempre inicializado; ele não tem flag de habilitação. | | Streaming | `STREAMING_ENABLED`, `STREAMING_BROKERS`, `STREAMING_TLS_ENABLED`, `STREAMING_TLS_CA_CERT` | Toggle de streaming de eventos de ciclo de vida, endereços de brokers compatíveis com Kafka, TLS e um certificado CA PEM opcional codificado em base64 para confiança em brokers privados. Base64 inválido ou conteúdo decodificado que não é PEM impede a inicialização. | | Auth | `PLUGIN_AUTH_ENABLED`, `AUTH_M2M_INVERSION_ENABLED` | Autorização de rotas e o gate obrigatório de inversão M2M para BYOC. | | Segurança de proxy | `TLS_TERMINATED_UPSTREAM`, `TRUST_PROXY_ENABLED`, `TRUSTED_PROXIES` | Terminação TLS no upstream e a lista restritiva de proxies confiáveis que ela exige em deploys endurecidos. | | Consignado | `CONSIGNADO_ENABLED` | O padrão é `true`. Ele controla apenas o tratamento legado de entrada de `consignado.averbacao.rejected`: a rota de contratação, o assinador de CCB e o consumidor de averbação confirmada foram aposentados. Quando você o desabilita, mantenha também `CONSUMER_CONSIGNADO_AVERBACAO_REJECTED_ENABLED` desligado; a inicialização rejeita essa configuração contraditória. A gestão da carteira de contratos existentes e os caminhos substitutos de contabilização e pagamento se configuram de forma independente. Veja [Consignado privado](/pt/products/lender/consignado-privado). | | Custódia M2M do ledger | `M2M_SECRETS_BACKEND`, `M2M_VAULT_MOUNT`, `AWS_REGION` | Backend de custódia das credenciais (AWS por padrão ou HashiCorp Vault KV v2), o mount KV dele e a região AWS quando AWS é selecionado. | | Contas do ledger | `MIDAZ_LEDGER_ACCOUNT_PROVISIONING_ENABLED` | O padrão é `true`. Antes de um relay lançar, o Lender garante que os aliases de conta não externos do perfil contábil existem; desabilite isso apenas quando você provisiona o plano de contas antes. Ele nunca cria ativos. | | Observabilidade | `ENABLE_TELEMETRY`, `OTEL_EXPORTER_OTLP_ENDPOINT` | Toggle de telemetria e endpoint do coletor OTLP. | | Limites | `RATE_LIMIT_ENABLED` | Rate limiting de requisições. Sempre ligado quando `ENV_NAME=production`. | | Docs | `SWAGGER_ENABLED` | Serve o documento OpenAPI e a UI de referência da API. Sempre desligado quando `ENV_NAME=production`. | ## Modos multi-tenant *** O Lender roda em um de dois modos: * **Single-tenant**: um tenant (`DEFAULT_TENANT_ID`), um schema de banco de dados, e uma organização de ledger e um ledger definidos na construção, usados como padrão de lançamento. * **Multi-tenant** (`MULTI_TENANT_ENABLED=true`): persistência com **schema por tenant**, um pool de clientes Midaz por tenant, e eventos e lançamentos delimitados por tenant. Nesse modo não existe padrão de ledger vindo do ambiente: o destino do ledger vem, por transação, do perfil contábil do produto. ## Lançamento no ledger e roteamento que falha fechado *** Uma contabilização chega ao ledger por uma intenção de lançamento durável e um relay assíncrono. O caminho inteiro está em [O Lender na plataforma](/pt/products/lender/lender-in-the-platform). O roteamento falha fechado. Um lançamento é contabilizado na organização de ledger e no ledger resolvidos a partir do perfil contábil. No modo single-tenant, um lançamento que não resolve nenhum destino do perfil recorre ao padrão do ambiente. Se nenhum dos dois resolver um destino não vazio, o Lender recusa lançar em vez de contabilizar em um ledger vazio ou errado. No modo multi-tenant, portanto, um produto sem perfil contábil não pode lançar. Essa proteção é intencional. ## Próximos passos *** O caminho de lançamento, o catálogo de eventos e o isolamento de tenants em detalhe.