Stack Components

The IntelliAsk stack is a set of independent services sharing one config/.env, each configured with the same variable names its container reads. This page explains how configuration is split per component and how each one is updated on its own.

The stack is one Docker Compose project made of independent services — the main IntelliAsk app plus its supporting components (Code Interpreter, the metrics exporter, MongoDB, MeiliSearch, RAG, and so on). They share a single config/.env, but every service owns its own block of that file, so you always know which settings belong to which component — and you can update each one on its own.

Main IntelliAsk app configuration

The main IntelliAsk application (intelliask service) is THE primary component and its configuration is covered in Configuration & Secrets, including INTELLIASK_* env vars, intelliask.yaml runtime config, endpoints, and app-level settings. This Components section documents the supporting services.

How configuration works

config/.env is the single source of truth, and each variable uses the same name the container reads — what you set in .env is exactly what the service sees, with no translation layer. Only the stack-level knobs that Compose itself consumes (not the container) carry a short per-service prefix so they're easy to group:

Key	Meaning
`<SERVICE>_IMAGE`	Image + tag for that service (e.g. `EXPORTER_IMAGE`, `RAG_IMAGE`).
`<SERVICE>_CPUS` / `<SERVICE>_MEMORY`	Resource ceilings for that service.
`<SERVICE>_PORT`	Published host port, where one is exposed.
`PROXY_` / `EXPORTER_PROXY_`	Reverse-proxy / Caddyfile settings.

Everything else is the application's own variable name — e.g. the exporter reads ENABLE_TOKEN_METRICS and MONGODB_URI, the RAG database uses POSTGRES_*, and the codeapi services read REDIS_* and SANDBOX_* — set under those exact names.

Each component page documents only its own keys

The per-component pages below list only that service's variables, config files, resource limits, and its own update steps. Cross-cutting topics that aren't owned by any single service — the .env concept, shared secrets, storage layout, and the full service map — stay in Configuration & Secrets.

Anatomy of a component

Every service is described the same way, in its own files:

A compose file — config/<service>.compose.yml defines the container, its ports, healthcheck, and resource limits.
A block in config/.env — its settings, under the same names the container reads (plus <SERVICE>_IMAGE / <SERVICE>_CPUS / <SERVICE>_MEMORY).
(Optional) a config file — mounted from config/ when the service needs more than env vars (e.g. the main app's intelliask.yaml).

That separation is what lets each component be updated independently.

Updating a single component

Because each service has its own image variable (<SERVICE>_IMAGE) and its own compose file, you roll out an update to one component without touching the rest:

# 1. Bump the image tag for that component in config/.env, e.g.
#    EXPORTER_IMAGE=intelliask-exporter:2.5.0
 
# 2. Pull + recreate ONLY that service
intelliask update exporter

The other containers keep running untouched. Use immutable tags (never reuse a tag) so a rollback is just putting the old tag back and re-running the update.

Use a new tag per release

Always publish each build under a new immutable tag and bump the matching <PREFIX>_IMAGE. Reusing a tag makes docker compose pull ambiguous and breaks clean rollbacks.

Component reference

Component	Configuration
Code Interpreter	Code Interpreter
Prometheus Exporter	Exporter
MongoDB	MongoDB
MeiliSearch	MeiliSearch
RAG API	RAG API
Vector DB (pgvector)	Vector DB
Redis	Redis
Garage (S3)	Garage
Reverse Proxy (Caddy)	Reverse Proxy