Skip to main content
Every application variable is prefixed with LAT_*. A few infrastructure variables (POSTGRES_*, CLICKHOUSE_*) are read directly by the bundled database containers. The committed .env.example is the canonical starting point — it documents both local development and production: copy it to .env.production and apply the values marked # For production on each line. Each variable is either required (the deployment won’t boot or function without it) or optional — it has a safe default, or it unlocks a feature that stays disabled until you set it (SSO, AI, email).

​
Secrets

Latitude needs two secrets, generated uniquely per deployment — never reuse the example values: Generate each with:
Moreover, remember to change the default infrastructure passwords (POSTGRES_PASSWORD_*, CLICKHOUSE_PASSWORD…) too!

​
Email

A working email transport is required for anyone to log in. Local development captures mail in Mailpit; production is not bundled with an email service — configure exactly one provider.

​
AI

The stack boots and core observability (ingest + trace viewing) works without API keys — AI-dependent features stay disabled, or fail, until you add the relevant provider key: Every internal AI capability is configurable through LAT_AI_* environment variables. With nothing set, the defaults uses Amazon Bedrock for generation and Voyage AI for embeddings and reranking.

​
Providers

You have to set the credentials for whichever providers you end up using:

​
Generation

Each feature resolves every setting through a three-tier fallback:
  1. Per-feature variable LAT_AI_<FEATURE>_<SETTING>
  2. Global variable LAT_AI_GENERATION_<SETTING>
  3. Built-in default minimax.minimax-m2.5
Available <SETTING>:
  • PROVIDER
  • MODEL
  • REASONING (none/default/minimal/low/medium/high/xhigh)
  • TEMPERATURE
  • MAX_TOKENS
Always set PROVIDER and MODEL together — model ids are provider-specific.

​
Embeddings

Embeddings are configured globally through LAT_AI_EMBEDDING_PROVIDER and LAT_AI_EMBEDDING_MODEL. It defaults to voyage / voyage-4-large, and powers semantic trace/signal search, search highlights, and signal clustering. Without a working embeddings provider, search falls back to lexical.
The embedding model is a one-time choice — pick it at install time and keep it.
Once an embedding model is used on a live deployment, changing it is a difficult task. Different models produce incompatible vector spaces and existing data is never re-embedded, so switching breaks semantic search, signal matching, and clustering. The model must also emit 2048-dimensional vectors — the dimension is fixed by the database schema and is not configurable.

​
Reranking

Reranking is configured globally through LAT_AI_RERANKING_PROVIDER and LAT_AI_RERANKING_MODEL. It defaults to voyage / rerank-2.5, and refines signal-discovery candidate matching. Reranking is optional — when unavailable, discovery falls back to embedding-order matching.

​
SSO

By default users sign in with email magic links. Add an OAuth provider to enable social sign-in:

​
Integrations

Optional, and cleanly no-op when unset:

​
Infrastructure

These wire Latitude to its datastores, depending on your chosen deployment option you can either point them to the bundled infrastructure services or bring your own infrastructure.

​
Application

​
Postgres

Primary store for projects, users, and metadata. Requires the vector (pgvector) extension.

​
ClickHouse

OLAP store for spans and telemetry, in a dedicated database.

​
Redis

Two Redis roles — a cache and the BullMQ job queue (same server or separate). Latitude namespaces all keys under latitude:, so it can share an instance with other apps.

​
Temporal

Workflow engine for durable background processes.

​
Object storage

Stores ingested payloads, datasets, and exports — shared by all services. Pick one of two drivers with LAT_STORAGE_DRIVER: fs writes to the local filesystem (a path or volume shared by every service), or s3 points at any S3-compatible service — AWS S3, SeaweedFS, MinIO, or any other managed or self-hosted store.