Skip to main content
This page provides a comprehensive reference for all environment variables and configuration options available in Omni.
All environment variables can be set in your .env file for Docker Compose deployments or in terraform.tfvars for AWS deployments.

Database Configuration

Redis Configuration

For Redis with password:

Application Configuration

Never use the same SESSION_SECRET across different environments. Generate unique secrets for dev, staging, and production.

Security & Encryption

Service Ports

Core Services

Connector Services

Optional Services

In Docker Compose, services communicate via service names (e.g., http://searcher:3001). Ports only need to be exposed to the host for debugging.

Docker Compose Resource Limits

Docker Compose deployments expose CPU and memory controls in .env.example. Defaults are conservative for a small single-node deployment and can be raised on larger hosts.

Inter-Service URLs

These URLs are used for internal communication between services. In Docker Compose, they use the service name and port variable interpolation.

Core Service URLs

Optional Service URLs

LLM Provider Configuration

LLM providers and models are configured through the Admin Panel (Settings > LLM Providers). API keys and other secrets are encrypted at rest in the database using ENCRYPTION_KEY and ENCRYPTION_SALT — they are never read from environment variables. Multiple providers can be active simultaneously, and users can select which model to use on a per-chat basis. Omni validates provider settings with a lightweight test call before saving them.

Supported Providers

Omni supports seven LLM provider types:

Predefined Models

When you add a provider, the following models are automatically available: Anthropic: Claude Opus 4.6, Claude Sonnet 4.5, Claude Haiku 4.5 OpenAI: GPT-5.2, GPT-5 Mini, GPT-4.1 Google Gemini: Gemini 3.5 Flash, Gemini 3.5 Pro, Gemini 3.1 Flash Lite AWS Bedrock: Claude Opus 4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Amazon Nova Pro Vertex AI: Claude Sonnet 4.5, Gemini 2.5 Pro, Gemini 2.5 Flash Azure AI Foundry: Claude Opus 4.6, Claude Sonnet 4.5, Claude Haiku 4.5, GPT-5.2, GPT-5 Mini, GPT-4.1 OpenAI-compatible: No predefined models — specify the model ID exposed by your endpoint.
Unlike the other provider types, OpenAI-compatible can be registered multiple times in a single instance — each configured endpoint (e.g. a local llama.cpp + a separate vLLM instance + an OpenRouter account) shows up as its own provider card in the admin panel, and its models become independently selectable per chat.

AWS Bedrock Environment Variables

Bedrock requests are made by the omni-ai service, so set these variables on omni-ai.
When running on EC2 or ECS with an appropriate IAM role, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN are not needed — the AWS SDK uses the EC2 instance profile or ECS task role automatically. You should still set AWS_REGION on omni-ai; EC2 metadata does not export it as an environment variable inside your host or containers.
For EC2 deployments using Docker, make sure the omni-ai container can reach the EC2 instance metadata service so the AWS SDK can retrieve role credentials. If IMDSv2 is enabled and credentials are not resolving inside containers, set the instance metadata response hop limit to 2. The role attached to omni-ai must allow the Bedrock models you configure. At minimum, include:
Also enable access to the chosen Bedrock models in the AWS console for the same region before testing the provider in Omni.

Vertex AI Environment Variables

Vertex AI uses Google Cloud Application Default Credentials (ADC). Configure region and project_id in the admin panel.
When running on GKE, Cloud Run, or Compute Engine with an attached service account, ADC is automatic — no environment variables are needed.

Azure AI Foundry Environment Variables

Azure AI Foundry uses DefaultAzureCredential (Managed Identity). Configure the endpoint_url in the admin panel.
When running on Azure (AKS, Container Apps, VMs) with Managed Identity configured, authentication is automatic. No additional environment variables are needed.

Self-hosted Local Inference

Omni ships a docker-compose.local-inference.yml overlay that starts a local llama.cpp container for LLM inference and (optionally) a HuggingFace TEI container for embeddings. Once running, register them as providers in the admin UI: OpenAI-compatible for the LLM pointed at http://llama-cpp:${LOCAL_INFERENCE_MODEL_PORT} and Local for the embedding provider.
The local LLM and embedding containers can be enabled independently — for example, cloud LLM with a local embedding model, or vice versa.

Web Search and Fetch Providers

Public web providers are configured through SettingsWeb Providers and stored encrypted in the database. They are optional and only affect agent tools; the Web Connector is configured separately as a connector source. Admins can connect multiple providers, set the current provider for each kind, override a provider base URL when needed, and maintain a URL blocklist. The fetch tool rejects localhost, private/internal IP addresses, and blocklisted domains or URL prefixes.

Feature Flags

Memory Configuration

Memory lets Omni recall selected context across future chats and agent runs. Set MEMORY_ENABLED=true, configure an embedding provider in the admin UI, then use SettingsMemory to choose the organization-wide default mode and memory LLM. The organization default is a ceiling: users can lower their personal memory level from SettingsMemory, but cannot choose a mode above the admin default.

Background Agents Configuration

Controls the background agent scheduler and execution limits. Requires AGENTS_ENABLED=true.

AI Service Configuration

Token usage for every LLM call (chat, agent run, compaction, title generation) is recorded in the model_usage table in Postgres, broken down by user, provider, and model. No additional configuration is required.

Conversation Compaction

Controls automatic compaction of long conversations to stay within model context limits.

Searcher Configuration

Connector Manager

The connector-manager service orchestrates all connector operations including scheduling syncs, health checks, and connector lifecycle management.

Document Conversion (Docling)

Docling is an optional service for extracting structured text from PDFs, Word documents, Excel files, PowerPoint, and common image formats. It can be toggled per-instance from SettingsDocument Conversion in the admin UI. When disabled, Omni falls back to lightweight built-in extractors. The same admin page also exposes a quality preset that controls how aggressively Docling parses each file: The preset is stored in Redis and picked up by indexers and connector-manager on every extraction — no restart needed.

Storage Configuration

PostgreSQL storage (default):
S3 storage:

Connector-Specific Configuration

Google Workspace Connector

Google Drive webhook URLs are derived from OMNI_DOMAIN as https://<domain>/google-webhook. Webhooks are disabled automatically when OMNI_DOMAIN=localhost.

Logging & Monitoring

Log level recommendations:
  • Development: RUST_LOG=debug
  • Production: RUST_LOG=info
  • Troubleshooting: RUST_LOG=trace

Telemetry (OpenTelemetry)

Example with Honeycomb: