> ## 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. # Multi-tenancy > Como o Lerian Cloud e os produtos BYOC com suporte isolam tenants, e como escolher armazenamento dedicado ou compartilhado. Multi-tenancy permite que um único deploy sirva contextos de cliente independentes (**tenants**), mantendo cada requisição e seus dados dentro do escopo do tenant autenticado. A Lerian opera o Lerian Cloud como um ambiente multi-tenant. No BYOC, multi-tenancy está disponível apenas para produtos e direitos de uso que oferecem suporte a ela. Um deploy BYOC Single-Tenant é uma configuração separada. ## Suporte por produto *** O escopo de tenant e a configuração são específicos de cada produto. A documentação do produto descreve atualmente a operação multi-tenant para: | Produto | Escopo documentado na documentação do produto | | :----------- | :-------------------------------------------------------------- | | **Midaz** | Organizações, ledgers, contas, transações e saldos. | | **Tracer** | Regras, limites, decisões de validação e eventos de auditoria. | | **Reporter** | Fontes de dados de relatório configuradas e relatórios gerados. | | **Matcher** | Recursos de conciliação. | Use o guia de autenticação e configuração do produto do qual você faz o deploy. Não suponha que uma variável de ambiente, um claim de JWT ou um comportamento de API documentado para um produto vale para outro. ## Autenticação e escopo das requisições *** Cada produto valida a identidade de quem chama e deriva o contexto de tenant conforme o contrato de autenticação daquele produto. Em um deploy multi-tenant, use o fluxo com suporte do Access Manager e inclua o token Bearer que o produto exige. A plataforma não define um claim `tenantId` universal nem um header de tenant universal para cada produto. Uma integração de produto deve seguir o claim e o comportamento de roteamento documentados daquele produto. Não acrescente um identificador de tenant a uma requisição a menos que aquele produto exija isso de forma explícita. Multi-tenancy é um recurso operacional, não uma promessa de que cada produto Lerian tem o mesmo middleware de autenticação ou a mesma superfície de configuração. ## Isolamento de armazenamento *** Os registros de serviço do Tenant Manager usam os valores `dedicated` e `shared`. Esta documentação usa os conceitos de deploy correspondentes abaixo: * **`DATABASE` (`dedicated`)**: um tenant recebe um banco de dados PostgreSQL dedicado. * **`SCHEMA` (`shared`)**: os tenants compartilham um banco de dados PostgreSQL e cada um recebe um schema dedicado. A distinção `DATABASE` / `SCHEMA` é específica do PostgreSQL. Outros datastores usam as próprias regras de roteamento e provisionamento por modo. Não deduza o comportamento de schema do PostgreSQL para MongoDB ou RabbitMQ. | Dimensão | `DATABASE` (`dedicated`) | `SCHEMA` (`shared`) | | :------------------------------ | :----------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------- | | **Isolamento no PostgreSQL** | Banco de dados separado por tenant. | Schema separado em um banco de dados compartilhado. | | **Raio de impacto operacional** | Um incidente no nível do banco de dados fica limitado ao banco daquele tenant. | Um incidente no nível do banco de dados pode afetar os tenants que compartilham a instância. | | **Custo e densidade** | Mais isolamento, mais infraestrutura por tenant. | Mais densidade, menos infraestrutura por tenant. | | **Desenho do restore** | Planeje e teste os restores para o banco de dados dedicado. | Planeje e teste os restores contra o banco de dados compartilhado e os schemas dele. | Escolha o modo por serviço conforme a configuração com suporte do serviço, as obrigações regulatórias, a carga de trabalho esperada e os requisitos de recuperação. ## Mover um tenant entre modos *** Mover um tenant do armazenamento compartilhado para o dedicado é uma migração planejada pelo operador, não um workflow automático genérico da plataforma. Valide o caminho de migração do produto de destino, os requisitos de consistência de dados, a janela de manutenção, o plano de backup/restore e o procedimento de rollback antes de mudar o registro de serviço de um tenant. A identidade do tenant pode continuar estável, mas não suponha que cada produto pode mover dados entre modos sem uma migração específica da implementação. ## Operar cada modelo de deploy *** ### Lerian Cloud A Lerian opera a infraestrutura multi-tenant. Siga a documentação de API e de autenticação do produto. O seu token e o contrato de roteamento do produto determinam o escopo da requisição. ### BYOC Multi-Tenant O operador configura os produtos com suporte, os serviços de tenant, o modo de armazenamento, os recursos de apoio e a autenticação. Trate a referência de configuração de cada produto como a fonte oficial. ### BYOC Single-Tenant ou desenvolvimento local Multi-tenancy não é automático. Os requisitos de autenticação dependem do produto e do ambiente. No Midaz, os deploys de produção e multi-tenant exigem autenticação. Um deploy single-tenant fora de produção que seja permitido pode desabilitá-la. ## Configuração *** Não existe um contrato de variáveis de ambiente entre produtos para multi-tenancy. Não copie uma lista genérica de variáveis `MULTI_TENANT_*` entre Midaz, Tracer, Reporter e Matcher. No Midaz, a operação multi-tenant exige a configuração específica do produto, incluindo `MULTI_TENANT_ENABLED`, `PLUGIN_AUTH_ENABLED` e `APPLICATION_NAME`. Confirme os valores atuais, os padrões e as dependências na referência de configuração do Midaz antes do deploy. Outros produtos têm os próprios contratos de configuração. ## Páginas relacionadas *** Como provisionar serviços de tenant e os recursos de apoio deles. Como escolher o isolamento dedicado ou compartilhado no PostgreSQL. Compare o Lerian Cloud, o BYOC Single-Tenant e as configurações BYOC Multi-Tenant com suporte. Entenda os fluxos de autenticação com suporte para os produtos dos quais você faz o deploy.