Configuration

IntelliApps is configured entirely through environment variables (optionally loaded from a local .env file). Every value is validated at startup; in non-development environments the service refuses to boot with placeholder secrets so an insecure deployment can't be created by accident.

Names below are the exact environment-variable names the container reads (case-insensitive). This page covers the core service; the per-feature tuning knobs for published pages live on Published-page features.

Core server

Secrets & signed tokens

Previews and downloads are authorised by HMAC-signed, time-limited tokens rather than sessions, so the service stays stateless.

Data planes

Persistence is split into three planes (see Architecture → data planes). Each backend is pluggable; the memory options exist for tests/local runs.

Control plane (MongoDB)

App-data plane (PostgreSQL)

Asset plane (S3)

Binary assets an app references (uploaded images, fonts) are stored content-addressed by SHA-256 in S3-compatible object storage, so the service stays stateless and identical bytes are never duplicated across versions.

Remote image fetch (web-search → asset)

The builder agent can pull an image it found on the web straight into the app's asset plane (the build sandbox has no network of its own, so the service performs the fetch — guarded against SSRF).

Upload & version limits

Theming

A served page's visual theme comes from /runtime/app-base.css. The choices are go-light, go-dark, light, dark, plus the none sentinel (platform theming off — the app's own CSS fully owns the page).

Deployment branding (company logo)

When configured, a logo is base64-inlined into every app's data bootstrap and auto-rendered in a page corner, surviving preview, publish, and the offline export (which has no server). Priority when several are set: data URI → URL → path.

Ask-the-data LLM

The published-page ask-the-data chat routes viewer questions back through IntelliAsk's model gateway using a service key. The cleanest setup is to leave the overrides blank and let it reuse the same chat credentials the IntelliAsk container already has (the ANTHROPIC_* values) — deploying in the same stack then needs no new LLM secrets.

Multiple selectable models

ASK_LLM_MODELS is a JSON array of profiles so each app can pick its own model. Any omitted provider/base_url/api_key inherits the effective defaults, so a single shared gateway sets its secret once and each extra model is just {"name","model"}:

[
  { "name": "haiku", "label": "Claude Haiku 4.5", "model": "claude-haiku-4-5" },
  { "name": "gpt4o", "label": "GPT-4o", "provider": "openai",
    "base_url": "https://gw/v1", "api_key": "${GW_KEY}", "model": "gpt-4o" }
]

The first entry is the default when an app doesn't choose. When empty, a single implicit profile is synthesized from the effective defaults.

Shared IntelliAsk chat provider (fallback)

Used whenever the ASK_LLM_* overrides are blank — mirror the env the IntelliAsk (LibreChat) container already sets:

Ask-the-data limits

Identity Bridge

Deployment/org policy defaults for the two identity planes (see Security → Identity Bridge).

Connecting to IntelliAsk

IntelliApps is reached by the IntelliAsk container as a native MCP server named intelliapps, injected automatically at container build when the two variables below are set on the IntelliAsk side. They are the intelliask-side counterpart of this service's HTML_APP_MCP_API_KEY.

When both are set, the IntelliAsk startup log shows [IntelliApps] Native MCP server "intelliapps" injected...; when they're missing it logs ... NOT injected — missing env: .... See Adding Environment Variables for how to wire a value through config/.env into the container.