Configuration & Secrets

Every setting lives in config/.env — the compose files contain no hardcoded configuration, only ${VARIABLE} references. This page covers the values you'll touch most.

config/.env — the single source of truth

config/.env holds all configuration and secrets. COMPOSE_FILE in it lists every *.compose.yml that makes up the stack, which is how one docker compose up brings them all up together. Which services actually run is decided by Docker Compose profiles, not by editing that list: every service carries a profile named after its module, and COMPOSE_PROFILES selects the active ones. The intelliask binary rewrites COMPOSE_PROFILES on every command from your enabled modules — see Optional modules.

After editing .env, apply changes with intelliask up (or up <service> for one service).

Secrets

The secrets command (run automatically during provisioning) fills any blank secret with a strong value. The managed secrets include:

SESSION_SECRET   CREDS_KEY   CREDS_IV   JWT_SECRET   JWT_REFRESH_SECRET
MEILI_MASTER_KEY   MONGO_ROOT_USERNAME   MONGO_ROOT_PASSWORD
GARAGE_RPC_SECRET   GARAGE_ADMIN_TOKEN   MINIO_ACCESS_KEY   MINIO_SECRET_KEY

You can fill blanks by hand, or regenerate them:

intelliask secrets gen            # fill only EMPTY values
intelliask secrets rotate         # regenerate ALL (fresh installs only)

Image registry

Every image is referenced as ${REGISTRY:-}${<SERVICE>_IMAGE}, so the stack is registry-agnostic. config/.env ships pointed at the public IntelliAsk registry, which serves all images — the main app, the six codeapi-* code interpreter images, and the supporting services — for anonymous pull, so no login is needed:

# config/.env (pre-set)
REGISTRY=registry.intelliask.mt/

To pull from your own registry instead, point REGISTRY at your mirror:

# config/.env
REGISTRY=registry.example.com/intelliask/

If that registry needs auth, docker login registry.example.com on the host once and pass --skip-login to provision. To switch one service rather than the whole stack, edit that service's image line directly in its compose file under config/:

# config/intelliask.compose.yml
services:
  intelliask:
    # was: image: ${REGISTRY:-}${INTELLIASK_IMAGE:-}
    image: registry.example.com/intelliask/intelliask:v0.8.7

Updating an image

Push the new build under a new immutable tag, then let update pull + recreate that one service. Either bump the matching <SERVICE>_IMAGE in config/.env first, or pass the tag inline with --version:

intelliask update intelliask                     # pull the tag already in .env
intelliask update --version v0.9.0 intelliask    # set the tag, then pull + recreate

Storage

All service data is bind-mounted under config/storage/ (one subfolder per service) so it can be inspected and backed up directly on the host. Change the location with STORAGE_ROOT in config/.env. Provisioning pre-creates the writable subdirectories (uploads-chat, public-images, code-interpreter-packages, license, license-state, …) with uid/gid 1000 ownership so the app can write to them.

Resource limits

Every service has a CPU/memory ceiling from config/.env (<SERVICE>_CPUS / <SERVICE>_MEMORY), with a matching fallback in each compose file. The defaults are sized for a 4 GiB / 2 vCPU host (memory ceilings total ~3.3 GiB). Raise them per host as needed, then intelliask up to apply. Check live usage with docker stats --no-stream.

Object storage (Garage S3)

The bundled garage service is a lightweight (~25 MB) self-hosted, S3-compatible store used by the Code Interpreter. On first start, intelliask garage (run automatically by provision) creates the cluster layout, the MINIO_BUCKET, and a deterministic access key (MINIO_ACCESS_KEY / MINIO_SECRET_KEY). It is idempotent and the S3 API stays internal-only (garage:3900).

IntelliAsk runtime config

Application-level configuration (endpoints, agents, MCP servers, UI options) lives in config/intelliask.yaml, mounted into the IntelliAsk container. Edit it there and restart the app:

intelliask restart intelliask

To add AI providers, see Custom Endpoints.

The service map

Optional modules

Some services are optional modules you can turn off when a deployment doesn't need them, or when you want to point the stack at an external equivalent instead of the bundled one. Toggle them with intelliask module:

intelliask module list                 # show every module and its state
intelliask module disable exporter     # stop + skip a module
intelliask module enable  exporter     # re-enable it
intelliask module disable garage --no-apply   # change .env only; apply later with `up`

Disabling a module drops its Compose profile from COMPOSE_PROFILES, so up, start, status, update and friends skip its containers entirely. The choice is recorded in DISABLED_MODULES in config/.env and survives restarts.

Core services (mongodb, meilisearch, intelliask) cannot be disabled — the app depends on them.

Alternative Deployment (Advanced)

For advanced users who prefer manual control, you can deploy using the compose files directly with docker compose commands. This approach:

• Requires Docker Compose knowledge — You manage service orchestration, environment variables, secrets, and updates manually
• Enables full customization — Substitute any bundled service with your own infrastructure:
  • Use your own S3 bucket instead of the bundled Garage
  • Connect to a managed Redis, PostgreSQL (pgvector), or MongoDB instance
  • Front with your own reverse proxy instead of the bundled Caddy
  • Customize resource limits, networks, volumes, or add sidecars
• Override via docker-compose.override.yml OR add to COMPOSE_FILE — Two ways to customize:
  • Place a docker-compose.override.yml in the same directory (Docker Compose auto-merges it)
  • OR create your own custom.compose.yml and add it to COMPOSE_FILE in config/.env

See Environment Variables > Docker Override for examples of substituting services and the official Docker Compose documentation for advanced orchestration patterns.