Skip to content

docs(env): document multi-tenant overlay envs (EVO-1631 NEST-3) #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
marcelogorutuba merged 1 commit into from
Jun 12, 2026
Merged

docs(env): document multi-tenant overlay envs (EVO-1631 NEST-3) #57

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions .env.example
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,31 @@
# EVO CAMPAIGN - CONFIGURAÇÃO DE AMBIENTE
# =============================================================================

# -----------------------------------------------------------------------------
# 🧩 EXTENSION POINTS BOOTSTRAP (multi-tenant overlay)
# -----------------------------------------------------------------------------
# Module specifier resolved by `loadExternalExtensions()` before
# `NestFactory.create`. When unset (default OSS run), evo-flow keeps the no-op
# extension-point implementations and behaves as a single-tenant deployment.
#
# To enable multi-tenant mode, install the enterprise overlay and set:
# EVO_EXTENSIONS_BOOTSTRAP=@evoapi/enterprise-licensing-nestjs
# The overlay's `register()` then wires the real `runtime_context` enricher
# (header + membership), the per-request RLS transaction runner, and the
# `TenantContextModule`.
EVO_EXTENSIONS_BOOTSTRAP=

# Read by the overlay's `tenant-config.ts`. When `false` (default) the overlay
# falls back to `DEFAULT_TENANT_ID` for every request — keeps single-tenant
# deployments and tests trivially working. Flip to `true` only when the
# membership SELECT is wired and the request header is being supplied.
MULTI_TENANT_ENABLED=false

# UUID assigned to every row in single-tenant mode (used by the overlay's
# migration `1763000000000-AddTenantIdAndRLSToAllEntities` to backfill existing
# data and by the overlay enricher when `MULTI_TENANT_ENABLED=false`).
DEFAULT_TENANT_ID=00000000-0000-0000-0000-000000000000

# =============================================================================
# Auth (evo-auth-service-community)
# =============================================================================
Expand Down Expand Up @@ -65,6 +90,10 @@ WRITE_MODE=kafka
# Para modo híbrido (integração com evo-ai-crm)
POSTGRES_DB_HOST=localhost
POSTGRES_DB_PORT=5432
# OSS default is `postgres` (superuser) so a vanilla `cp .env.example .env`
# works out of the box. Multi-tenant deployments MUST switch this to a
# NOBYPASSRLS role (e.g. `evo_app`, provisioned by evo-enterprise-docker's
# postgres-init, story EVO-1620) so the overlay's RLS policies actually filter.
POSTGRES_DB_USERNAME=postgres
POSTGRES_DB_PASSWORD=password
POSTGRES_DB_DATABASE=evo_campaign
Expand Down
Loading