Adding Environment Variables

config/.env is the single source of truth, but a variable only reaches a container if a compose file references it. The stack deliberately does not dump the whole .env into every service — each service lists exactly the variables it needs as KEY: ${KEY:-default}. Adding your own value is a two-line change plus one apply.

Step 1. Declare it in config/.env

Add the variable (and, ideally, a labelled comment) to config/.env:

# config/.env
 
# --- My feature ---
MY_FEATURE_TOKEN=super-secret-value

Grouping it under a clear section keeps .env readable. For secrets you'd rather have generated for you, leave the value blank so intelliask secrets gen can fill it — see Secrets.

Step 2. Reference it in the compose file

Open the compose file for the service that needs the value (e.g. config/intelliask.compose.yml) and add the variable to that service's environment: map, using the same ${VAR:-fallback} interpolation pattern as the rest of the stack:

services:
  intelliask:
    # ...
    environment:
      # --- My feature ---
      MY_FEATURE_TOKEN: ${MY_FEATURE_TOKEN:-}

• ${MY_FEATURE_TOKEN:-} injects the value from .env, or an empty string when it's unset — this is why the app never crashes on a missing optional variable.
• Use ${MY_FEATURE_TOKEN:-somedefault} to bake in a default when the var is blank.
• The name on the left is what the container sees; the ${...} on the right is what's read from .env. They're usually identical, but don't have to be.

Adding a brand-new compose file

If your customisation is large enough to warrant its own service or override, create a custom.compose.yml and register it so docker compose loads it alongside the rest of the stack — either append it to COMPOSE_FILE in config/.env:

# config/.env
COMPOSE_FILE=...:custom.compose.yml

…or drop a docker-compose.override.yml next to the compose files (Compose merges it automatically). See Alternative Deployment for the trade-offs.

Step 3. Apply

Recreate the affected service so it picks up the new environment. Compose only re-reads .env and re-injects variables when the container is (re)created, so a plain restart is not enough:

intelliask up intelliask      # just one service
intelliask up                 # or the whole stack

Confirm the value landed inside the container:

docker compose exec intelliask printenv MY_FEATURE_TOKEN

Worked example: connecting IntelliApps

IntelliApps is a good example of wiring a value into the IntelliAsk container. IntelliAsk reaches it as a native MCP server that is injected automatically at container build only when two variables are present:

Declare them in config/.env:

# config/.env
 
# --- IntelliApps ---
INTELLIAPPS_API_URL=http://intelliapps:8000
INTELLIAPPS_SERVICE_KEY=            # must match IntelliApps' HTML_APP_MCP_API_KEY

Reference them on the intelliask service:

services:
  intelliask:
    # ...
    environment:
      # --- IntelliApps ---
      INTELLIAPPS_API_URL: ${INTELLIAPPS_API_URL:-}
      INTELLIAPPS_SERVICE_KEY: ${INTELLIAPPS_SERVICE_KEY:-}

Then intelliask up intelliask. On start the app logs [IntelliApps] Native MCP server "intelliapps" injected… when both are set, or … NOT injected — missing env: … when one is absent.