> ## 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

> Cómo Lerian Cloud y los productos BYOC compatibles aíslan tenants, y cómo elegir almacenamiento dedicado o compartido.

Multi-tenancy permite que un despliegue sirva contextos de cliente independientes (**tenants**) y mantiene cada solicitud y sus datos dentro del ámbito del tenant autenticado.

Lerian opera Lerian Cloud como un entorno multi-tenant. En BYOC, multi-tenancy está disponible solo para los productos y las habilitaciones que lo admiten. Un despliegue BYOC Single-Tenant es una configuración aparte.

## Compatibilidad por producto

***

El alcance por tenant y la configuración son específicos de cada producto. La documentación de producto describe actualmente la operación multi-tenant para:

| Producto     | Alcance documentado en su documentación de producto               |
| :----------- | :---------------------------------------------------------------- |
| **Midaz**    | Organizaciones, ledgers, cuentas, transacciones y saldos.         |
| **Tracer**   | Reglas, límites, decisiones de validación y eventos de auditoría. |
| **Reporter** | Fuentes de datos de informes configuradas e informes generados.   |
| **Matcher**  | Recursos de conciliación.                                         |

Usa la guía de autenticación y configuración del producto que despliegas. No supongas que una variable de entorno, un claim de JWT o un comportamiento de API documentado para un producto se aplica a otro.

## Autenticación y alcance de las solicitudes

***

Cada producto valida la identidad de quien llama y deriva su contexto de tenant según el contrato de autenticación de ese producto. En un despliegue multi-tenant, usa el flujo de Access Manager admitido e incluye el token Bearer que el producto requiere.

La plataforma no define un claim `tenantId` universal ni un header de tenant universal para cada producto. Una integración de producto debe seguir el claim y el comportamiento de enrutamiento documentados de ese producto. No agregues un identificador de tenant a una solicitud a menos que ese producto lo requiera explícitamente.

<Note>
  Multi-tenancy es una capacidad operativa, no una promesa de que cada producto de Lerian tiene el mismo middleware de autenticación o la misma superficie de configuración.
</Note>

## Aislamiento del almacenamiento

***

Los registros de servicio de Tenant Manager usan los valores `dedicated` y `shared`. Esta documentación usa los conceptos de despliegue correspondientes de abajo:

* **`DATABASE` (`dedicated`)**: un tenant recibe una base de datos PostgreSQL dedicada.
* **`SCHEMA` (`shared`)**: los tenants comparten una base de datos PostgreSQL y cada uno recibe un esquema dedicado.

La distinción entre `DATABASE` y `SCHEMA` es específica de PostgreSQL. Otros datastores usan sus propias reglas de enrutamiento y aprovisionamiento por modo. No deduzcas el comportamiento de esquemas de PostgreSQL para MongoDB o RabbitMQ.

| Dimensión                      | `DATABASE` (`dedicated`)                                                              | `SCHEMA` (`shared`)                                                                               |
| :----------------------------- | :------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------ |
| **Aislamiento de PostgreSQL**  | Base de datos separada por tenant.                                                    | Esquema separado en una base de datos compartida.                                                 |
| **Radio de impacto operativo** | Un incidente en el nivel de base de datos se limita a la base de datos de ese tenant. | Un incidente en el nivel de base de datos puede afectar a los tenants que comparten la instancia. |
| **Costo y densidad**           | Mayor aislamiento, más infraestructura por tenant.                                    | Mayor densidad, menos infraestructura por tenant.                                                 |
| **Diseño de restauración**     | Planifica y prueba las restauraciones para la base de datos dedicada.                 | Planifica y prueba las restauraciones contra la base de datos compartida y sus esquemas.          |

Elige el modo por servicio según la configuración admitida del servicio, las obligaciones regulatorias, la carga de trabajo esperada y los requisitos de recuperación.

## Mover un tenant entre modos

***

Mover un tenant de almacenamiento compartido a dedicado es una migración planificada por el operador, no un workflow automático genérico de la plataforma. Valida la ruta de migración del producto objetivo, los requisitos de consistencia de datos, la ventana de mantenimiento, el plan de backup y restauración, y el procedimiento de rollback antes de cambiar el registro de servicio de un tenant.

La identidad del tenant puede permanecer estable, pero no supongas que cada producto puede mover datos entre modos sin una migración específica de la implementación.

## Operar cada modelo de despliegue

***

### Lerian Cloud

Lerian opera la infraestructura multi-tenant. Sigue la documentación de API y de autenticación del producto. Tu token y el contrato de enrutamiento del producto determinan el ámbito de la solicitud.

### BYOC Multi-Tenant

El operador configura los productos admitidos, los servicios de tenant, el modo de almacenamiento, los recursos subyacentes y la autenticación. Trata la referencia de configuración de cada producto como la fuente autorizada.

### BYOC Single-Tenant o desarrollo local

Multi-tenancy no es automático. Los requisitos de autenticación dependen del producto y del entorno. Para Midaz, los despliegues de producción y multi-tenant requieren autenticación. Un despliegue single-tenant fuera de producción que esté permitido puede deshabilitarla.

## Configuración

***

No hay un contrato de variables de entorno común entre productos para multi-tenancy. No copies una lista genérica de variables `MULTI_TENANT_*` entre Midaz, Tracer, Reporter y Matcher.

Para Midaz, la operación multi-tenant requiere su configuración específica de producto, incluidas `MULTI_TENANT_ENABLED`, `PLUGIN_AUTH_ENABLED` y `APPLICATION_NAME`. Confirma los valores actuales, los predeterminados y las dependencias en la referencia de configuración de Midaz antes de desplegar. Otros productos tienen sus propios contratos de configuración.

## Páginas relacionadas

***

<CardGroup>
  <Card title="Aprovisionamiento automático" icon="wand-magic-sparkles" href="/es/platform/multi-tenancy/auto-provisioning" cta="Ver aprovisionamiento">
    Cómo aprovisionar servicios de tenant y sus recursos subyacentes.
  </Card>

  <Card title="Casos de uso" icon="lightbulb" href="/es/platform/multi-tenancy/use-cases" cta="Ver ejemplos">
    Cómo elegir el aislamiento de PostgreSQL dedicado o compartido.
  </Card>

  <Card title="Modelos de despliegue" icon="cloud" href="/es/start-here/evaluate-and-deploy/deployment-models" cta="Comparar modelos">
    Compara Lerian Cloud, BYOC Single-Tenant y las configuraciones BYOC Multi-Tenant admitidas.
  </Card>

  <Card title="Access Manager" icon="key" href="/es/platform/access-manager" cta="Conoce la autenticación">
    Comprende los flujos de autenticación admitidos para los productos que despliegas.
  </Card>
</CardGroup>
