Tenants

Modelo multi-tenant de Vertix: aislamiento por schema, ciclo de vida, y operaciones administrativas.

Modelo de tenancy

Vertix usa schema-per-tenant sobre una sola base de datos PostgreSQL. Cada tenant tiene:

• Slug único URL-safe → subdominio <slug>.vertix.lat
• Schema dedicado tenant_<slug> con sus tablas
• Configuración Caddy reverse_proxy específica
• Plan, niche, primaryLocale, status

Estados (status)

• pending — provisionado, esperando primer login owner
• active — operativo
• grace — pago vencido, acceso degradado por 7 días
• read_only — lectura solo, sin mutaciones
• suspended — bloqueado completamente
• archived — schema preservado pero no accesible

Aislamiento de datos

Cada query a datos de tenant aplica SET LOCAL search_path TO tenant_<slug>, public antes de ejecutar. SET LOCAL se resetea al COMMIT, compatible con PgBouncer transaction pooling.

El slug se valida con regex /^[a-z][a-z0-9_-]+$/ ANTES de interpolar como identificador SQL para prevenir injection.

Crear un tenant

Solo superadmin via admin.vertix.lat/tenants/new. Se ejecuta:

1. Validar slug + reserved list
2. Insertar fila en public.tenants
3. Ejecutar CREATE SCHEMA IF NOT EXISTS tenant_<slug>
4. Aplicar DDL base (memberships scoped, audit local, etc)
5. Configurar Caddy file + reload
6. Audit log tenant.create

Archivar / eliminar

Vertix no elimina tenants. Archivar cambia status a archived, schema preservado para recuperación. Backup completo via pgBackRest antes de archivar.

Resolución por subdomain

resolveTenant en @vertix/core/tenant:

1. Extrae slug del Host header
2. Valida contra reserved list
3. Busca tenant en LRU cache (60s TTL)
4. Si miss: query public.tenants WHERE slug = ?
5. Retorna tenant o null (404)

Cache invalidation: invalidateTenantCache(slug) tras update administrativo.

Ver también

• Modules — qué se instala dentro del tenant
• API keys — autenticación per-tenant