> ## 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 e o caminho de lançamento no ledger. O Lender é um único serviço Go, empacotado como container e configurado 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 (Uma plataforma para executar e gerenciar aplicações de software em escala, que lida automaticamente com deploy, escalabilidade e recuperação em vários servidores.) com o [ferramental de ciclo de vida](https://docs.lerian.studio/pt/platform/lifecycle-management.md) 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. | | **Valkey 8** (compatível com Redis) | Cache, rate limiting e o cache de credenciais M2M. | | **RabbitMQ** | Opcional e desligado por padrão. Ele não é o transporte do catálogo de eventos do Lender. | | **RedPanda** | Backbone de eventos compatível com Kafka para fatos de ciclo de vida, publicados pela biblioteca de streaming da Lerian e pelo outbox transacional. Obrigatório: o serviço não inicia sem ele. | | **Midaz** | O ledger (O livro financeiro central que registra todas as transações, saldos e operações de uma organização. É a fonte única de verdade para as finanças de uma unidade de negócio.) de partidas dobradas, alcançado pelo SDK oficial. O Lender se autentica pelo [Access Manager](https://docs.lerian.studio/pt/platform/access-manager.md) com credenciais máquina a máquina (M2M). Você as guarda no seu cofre de segredos (veja a custódia das credenciais M2M do ledger abaixo). | | **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 é 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 | `DEFAULT_TENANT_ID` | O tenant que o deploy atende. | | 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` | O backbone de eventos, endereços de brokers compatíveis com Kafka, TLS e um certificado CA PEM opcional codificado em base64 para confiança em brokers privados. A inicialização exige `STREAMING_ENABLED=true` e pelo menos um broker. 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, ligada por padrão, 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 o tratamento de entrada de `consignado.averbacao.rejected`. 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 de contabilização e pagamento se configuram de forma independente. Veja [Consignado privado](https://docs.lerian.studio/pt/products/lender/consignado-privado.md). | | Custódia M2M do ledger | `M2M_SECRETS_BACKEND`, `M2M_VAULT_MOUNT`, `AWS_REGION` | Onde as credenciais M2M do ledger ficam no seu próprio deploy. Na Lerian Cloud, a Lerian as gerencia. | | 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`. | ## Tenant e padrões de ledger *** Por padrão, o Lender atende um tenant (`DEFAULT_TENANT_ID`) com um schema de banco de dados. ## 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](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md). O roteamento falha fechado. Um lançamento é contabilizado na organização de ledger e no ledger resolvidos a partir do perfil contábil. 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. ## Próximos passos *** > [card] [O Lender na plataforma](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md) > > O caminho de lançamento, o catálogo de eventos e o isolamento de tenants em detalhe. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.