Skip to main content
En un despliegue BYOC (bring your own cloud), ejecutas los productos de Lerian dentro de tu propia infraestructura de AWS, GCP u on-premise. Tú eres dueño de los datos y del runtime. Configuras cada servicio mediante variables de entorno, y la mayoría son específicas del servicio. Esta página cubre el eje común: las variables que se comportan igual en todos los servicios de Lerian en Go. Configura una vez los parámetros que aplican a todo el despliegue y usa la página propia de cada producto para el resto. Para Pix Lerian v1.0.0, la configuración BYOC admite los componentes entregados y la vía de integración/pruebas con el adaptador simulado. No hace disponible el conector de mensajería nativa de SPI ni convierte el adaptador simulado en un riel de producción.
Estas variables forman el eje común, no la lista completa. Los prefijos de las variables difieren un poco entre servicios (por ejemplo, un servicio con bases de datos separadas para onboarding y transacciones las organiza con espacios de nombres distintos), y cada servicio agrega sus propias claves. Consulta Variables por producto para ver las listas completas.

Modo de despliegue y TLS

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

Servidor

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

Almacenes de datos

Todo 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 siguiente tabla muestra la forma común. Consulta la página de cada producto para conocer los nombres exactos.
No todos los servicios usan todos los almacenes, y los prefijos varían. Los productos principales suelen organizar las conexiones por base de datos lógica (por ejemplo, DB_ONBOARDING_*, DB_TRANSACTION_*, MONGO_CRM_*). Los plugins y los rieles usan la forma plana POSTGRES_* de arriba. En modo multi-tenant, el servicio ignora las credenciales estáticas de almacenamiento y resuelve las conexiones por tenant (ver más abajo).

Multi-tenancy

Multi-tenancy está deshabilitado de forma predeterminada. Cuando lo habilitas, cada conexión de almacenamiento de datos pasa de la configuración estática a la resolución por tenant a través de Tenant Manager. El servicio también agrega un sondeo de readiness por tenant en GET /readyz/tenant/{id}.
Existen parámetros adicionales por servicio para el tamaño del pool por tenant, el circuit breaker y el TTL de la caché (MULTI_TENANT_MAX_TENANT_POOLS, MULTI_TENANT_CIRCUIT_BREAKER_*, MULTI_TENANT_CACHE_TTL_SEC, entre otros). Consulta las páginas de cada producto.

Configuración de runtime

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

Streaming y outbox

La vía de publicación de eventos (un productor de lib-streaming respaldado por un outbox transaccional) está deshabilitada de forma predeterminada en la mayoría de los servicios. La excepción son los rieles nativos (por ejemplo, SPI y SILOC), que no exponen STREAMING_ENABLED en absoluto. En esos rieles, el streaming no tiene modo deshabilitado: STREAMING_BROKERS es obligatoria, y el servicio se niega a iniciar cuando ese valor falta o no es válido. Consulta la página de cada producto para conocer su contrato.
STREAMING_SASL_* y STREAMING_TLS_* protegen la conexión con el broker. Configúralas cuando tu broker exija autenticación o TLS.

Descubrimiento de servicios

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

Observabilidad

La telemetría funciona por envío (push, OTLP). Algunos servicios también exponen un endpoint /metrics para el scraping de Prometheus. Consulta Salud y readiness.

Autenticación de plugins

Los servicios de Lerian pueden autenticar rutas protegidas, incluida la API de administración de systemplane, a través de Access Manager (respaldado por Caradhras). El interruptor de autenticación, el nombre de su variable y su valor predeterminado varían según el servicio. La mayoría de los plugins y productos usan PLUGIN_AUTH_ENABLED (predeterminado false, deshabilitado). Los rieles nativos como SILOC y SPB usan AUTH_ENABLED (predeterminado true, habilitado, obligatorio en producción y en SaaS) junto con AUTH_ADDRESS. Habilita siempre la autenticación en producción. Consulta la página de variables de entorno propia de cada producto o riel para conocer el nombre autoritativo del interruptor, su valor predeterminado y las rutas que protege.

Variables por producto

Las variables anteriores forman la base común. Cada producto agrega las suyas: prefijos de almacenamiento de datos, URLs de integración, ajustes de workers e interruptores de funcionalidad. Usa las páginas de cada producto para ver la lista completa y actualizada:

Midaz

Tracer

Reporter

Flowker

Lender

La lista exhaustiva de variables por servicio se distribuye en el archivo .env.example de cada servicio. Trátalo como la fuente de verdad para una versión específica y nunca subas valores reales de secretos en él.