Saltar al contenido principal
En un despliegue BYOC (bring your own cloud), ejecutas los productos de Lerian dentro de tu propia infraestructura de AWS, GCP o en las instalaciones, y eres dueño de los datos y del entorno de ejecución. Cada servicio se configura mediante variables de entorno, y la mayoría de ellas son específicas del servicio. Esta página cubre la base universal —las variables que se comportan igual en todos los servicios Go de Lerian— para que definas los ajustes de todo el despliegue una sola vez y luego recurras a la página propia de cada producto para el resto.
Esta es la base compartida, no la lista completa. Los prefijos de las variables difieren ligeramente entre servicios (por ejemplo, un servicio con bases de datos de onboarding y de transacciones separadas les asigna espacios de nombres distintos), y cada servicio añade sus propias claves. Consulta Variables por producto para ver las listas exhaustivas.

Modo de despliegue y TLS

DEPLOYMENT_MODE define con qué rigor el servicio impone TLS en sus conexiones de infraestructura, y su valor se refleja en la respuesta de /readyz.
Para un despliegue BYOC de producción, define DEPLOYMENT_MODE=byoc, conecta cada almacén de datos por TLS y deja ALLOW_INSECURE_TLS sin definir (false). Los valores por defecto de local entregan conexiones en texto plano y no son seguros para producción.

Servidor

Algunos servicios exponen un SERVER_PORT numérico en lugar de, o junto con, SERVER_ADDRESS. Los componentes de tipo worker sin una API HTTP principal exponen un puerto de salud dedicado (por ejemplo HEALTH_PORT o WORKER_SERVER_PORT). Consulta Puertos de red por defecto y Salud y readiness.

Almacenes de datos

Cada servicio que persiste estado se conecta a uno o más almacenes de datos. El prefijo de la variable depende del almacén y, en algunos servicios, de la base de datos lógica. La tabla siguiente muestra la forma común; consulta la página de cada producto para los nombres exactos.
No todos los servicios usan todos los almacenes, y los prefijos varían: los productos centrales suelen asignar espacios de nombres a las conexiones por base de datos lógica (por ejemplo DB_ONBOARDING_*, DB_TRANSACTION_*, MONGO_CRM_*), mientras que los plugins y los rieles usan la forma plana POSTGRES_* anterior. En modo multi-tenant, las credenciales estáticas de los almacenes de datos se ignoran: las conexiones se resuelven por tenant (ver más abajo).

Multi-tenancy

El multi-tenancy está desactivado por defecto. Cuando lo habilitas, cada conexión a un almacén de datos pasa de la configuración estática a la resolución por tenant a través de Tenant Manager, y el servicio añade una sonda de readiness por tenant en GET /readyz/tenant/{id}.
Existen ajustes adicionales por servicio para dimensionar el pool por tenant, el circuit breaker y el TTL de caché (MULTI_TENANT_MAX_TENANT_POOLS, MULTI_TENANT_CIRCUIT_BREAKER_*, MULTI_TENANT_CACHE_TTL_SEC, y otros). Consulta las páginas por producto.

Configuración en tiempo de ejecución

Cuando está habilitada, el servicio expone un plano autenticado para leer y escribir la configuración en tiempo de ejecución. Consulta Systemplane para la API, los espacios de nombres y los permisos requeridos.

Streaming y outbox

La ruta de publicación de eventos (un productor de lib-streaming respaldado por un outbox transaccional) está desactivada por defecto en todos los servicios excepto en el worker de Fetcher, que define STREAMING_ENABLED=true para emitir eventos de finalización de trabajos.
STREAMING_SASL_* y STREAMING_TLS_* aseguran la conexión al broker: defínelas cuando tu broker requiera autenticación o TLS.

Descubrimiento de servicios

El descubrimiento de servicios con Consul está desactivado por defecto. Cuando está habilitado, el servicio se registra a sí mismo y resuelve a sus pares a través de Consul en lugar de direcciones estáticas.
Algunos servicios usan alias heredados (SD_ADVERTISE_*, CONSUL_ADDR) para el mismo comportamiento.

Observabilidad

La telemetría es basada en push (OTLP). Algunos servicios exponen además un endpoint /metrics para el scraping de Prometheus; consulta Salud y readiness.

Autenticación de plugins

Los servicios de Lerian pueden autenticar las rutas protegidas —incluida la API de administración de Systemplane— a través de Access Manager (respaldado por Casdoor). El toggle de autenticación, su nombre de variable y su valor por defecto difieren según el servicio: la mayoría de los plugins y productos usan PLUGIN_AUTH_ENABLED (por defecto false, desactivado), mientras que los rails nativos como SILOC y SPB usan AUTH_ENABLED (por defecto true, activado —obligatorio en producción y SaaS) junto con AUTH_ADDRESS. Activa siempre la autenticación en producción y consulta la página de variables de entorno de cada producto o rail para conocer el nombre del toggle, su valor por defecto y las rutas que protege.

Variables por producto

Las variables anteriores son la base compartida. Cada producto añade las suyas: prefijos de almacenes de datos, URL de integración, ajuste de workers y toggles de funcionalidades. Usa las páginas por producto para la lista completa y actual:

Midaz

Tracer

Reporter

Flowker

Lender

Fetcher

La lista exhaustiva de variables por servicio se entrega en el archivo .env.example de cada servicio. Trátalo como la fuente de verdad para un release específico, y nunca incluyas valores secretos reales en él.