Skip to main content
Prisme.ai services can be configured through various environment variables. This reference provides a comprehensive list of available configuration options for your deployment.

Configuration Methods

Docker Setup

In a Docker deployment, configure these variables in the root docker-compose.yml file. See the Docker Compose documentation for more details.

Developer Setup

In a development environment, create a services/*/.env file containing key/value pairs:
To run a service directly from its Docker image, add an env_file option to its services/*/docker-compose.yml file:
Note 1: Default values may differ depending on the selected start mode (Docker or Developer), especially URL-related variables. Note 2: Relative paths start from the executing service directory.

Variable Categories

Domains & URLs

Configure the URLs and domains used by Prisme.ai services.

Databases & Storage

Redis Configuration

MongoDB/PostgreSQL Configuration

Elasticsearch Configuration

Storage Configuration

Prisme.ai supports multiple storage backends for workspaces and uploads. Available storage types are:
  • FILESYSTEM: Local file system storage
  • S3_LIKE: Amazon S3 or compatible services (MinIO, etc.)
  • AZURE_BLOB: Azure Blob Storage
  • GCS : Google Cloud Storage

Workspaces Storage

Do not use FILESYSTEM for workspaces models in production. Filesystem writes are not atomic, so concurrent writes to the same workspace (multiple runtime / workspaces replicas, or an RWX volume shared across pods) can interleave and leave corrupted model YAML files. Use an object storage backend (S3_LIKE, AZURE_BLOB or GCS) instead, which writes each object atomically. Reserve FILESYSTEM for local development or single-replica evaluation setups.

S3-Compatible Storage for Workspaces

Azure Blob Storage for Workspaces

GCS Storage for Workspaces

If WORKSPACES_STORAGE_GCS_KEYFILEPATH or GOOGLE_APPLICATION_CREDENTIALS is provided, only WORKSPACES_STORAGE_GCS_BUCKET is required.

File Uploads Storage

S3-Compatible Storage for uploads

Azure Blob Storage for uploads

With an Azure identity configured, the connection string is ignored (a warning is logged if one is still set) and the identity needs the Storage Blob Data Contributor role on the account. See Microsoft Entra ID passwordless auth.

GCS Storage for uploads

If UPLOADS_STORAGE_GCS_KEYFILEPATH or GOOGLE_APPLICATION_CREDENTIALS is provided, only UPLOADS_STORAGE_GCS_BUCKET is required. Notes on uploads bucket: By default, a single private bucket holds both public and private uploads. Every download is proxied by the api-gateway, which checks the file’s visibility and serves public files without requiring authentication. No CDN, no public bucket, and no object-level ACLs are required. The default applies as long as UPLOADS_STORAGE_*_BASE_URL is left unset. If you want public files to be served directly from a CDN instead of through the api-gateway, you can opt into a two-bucket setup:
  1. Keep the private bucket as-is (UPLOADS_STORAGE_S3_*).
  2. Add a second bucket dedicated to public assets (UPLOADS_PUBLIC_STORAGE_S3_*), exposed through a CDN.
  3. Set UPLOADS_STORAGE_S3_LIKE_BASE_URL (and/or UPLOADS_PUBLIC_STORAGE_S3_LIKE_BASE_URL) to the CDN’s public base URL; that is what tells the platform to hand out direct CDN URLs instead of proxying through the api-gateway.
You can reuse the same credentials for both buckets or provide separate ones:
Equivalent variables exist for GCS:
To switch back to “everything through the api-gateway”, simply unset the UPLOADS_STORAGE_*_BASE_URL variables.

Authentication & Security

OIDC Configuration

Declaring external OIDC clients (native mobile apps)

Besides the studio, whose redirect_uris are web console URLs, the api-gateway also ships a default native client for the Prisme.ai mobile app so it works out of the box — no configuration needed:
Set OIDC_EXTERNAL_CLIENTS to override this default and declare your own public clients — the variable replaces the built-in mobile client entirely, so re-add it if you still need it. The value is a JSON array of oidc-provider client metadata objects. Only client_id and redirect_uris are required; the api-gateway applies defaults so every entry is treated as a public PKCE native client: PKCE is automatically required for these public clients — no extra setting needed.
For a native client, oidc-provider validates the redirect_uris per RFC 8252:
  • Custom URI scheme → must be reverse-domain (the scheme must contain a .). ai.prisme.app://oauth/callback is accepted, prisme://oauth/callback is rejected.
  • https → accepted (universal / claimed link), non-loopback hostname.
  • http → only for loopback addresses (127.0.0.1, [::1]).
An invalid redirect_uri makes the api-gateway fail to boot, so validate the value before deploying.
Example — override with a custom client (keeping the default mobile client too):
The mobile app then drives the flow with PKCE (e.g. ASWebAuthenticationSession(callbackURLScheme: "ai.prisme.app") on iOS). Universal / app links (Apple apple-app-site-association, Android assetlinks.json) are not required for a custom scheme.

Session & Token Configuration

Security Settings

Service-Specific Configuration

API Gateway

Console

Events Service

Runtime Service

FETCH_ALLOW_H2 and LLM streaming. Some corporate egress proxies and TLS-inspecting gateways buffer entire HTTP/1.1 response bodies before forwarding them. This breaks Server-Sent Events from LLM providers: the agent’s answer reaches the browser in one block at the end of generation instead of token by token. HTTP/2 usually traverses those same proxies unbuffered.
Bounding silent peers. FETCH_HEADERS_TIMEOUT and FETCH_BODY_TIMEOUT are inactivity bounds, not total duration caps, so a long streaming completion is never cut off. Their purpose is the opposite case: a host that accepts the connection and then says nothing, which used to hold the calling automation for the full 300s without emitting anything. Authors can tighten a single call with the fetch instruction’s timeout option, see Automations → fetch.
WORKER_STREAM_FIRST_CHUNK_TIMEOUT and slow models. When a model takes longer than this to emit its first token, the run now ends on an explicit time-to-first-token error, rather than on the generic “LLM gateway stream returned no data”. Large generations on some providers legitimately exceed 60s to start; raise the variable rather than reading the error as a platform failure.
Cancelled executions. WEBHOOKS_ABORT_ON_CLOSE and EXECUTION_ABORT_GRACE_PERIOD govern how the runtime stops an execution nobody waits for anymore, such as an agent answer the user stopped: the provider request is closed, so its tokens stop being generated and billed. See Automations → Cancelling an execution for what automations see.
FETCH_EMIT_REQUEST_EVENT for outbound-traffic auditing. Off by default. When enabled, every fetch instruction emits a runtime.fetch.requested event just before the request is dispatched — so a call that hangs, times out or crashes still leaves a trace of the URL it targeted. The payload carries request metadata only (method, URL, header names, content-type, body size) and never any request body nor any header value, so it is safe to persist and search. Failures are still reported separately by runtime.fetch.failed. Intra-platform workspace→workspace calls (webhook direct calls) are not audited. Platform-wide switch only — it cannot be toggled per fetch.

Workspaces Service

Platform Repositories

Platform repositories are shared repositories automatically available to all workspaces for versioning (push/pull). They are configured entirely through environment variables and require no per-workspace setup. Each workspace’s files are stored in a subdirectory named after the workspace slug within the repository. This allows a single repository to serve as a centralized versioning backend for every workspace on the platform. Multiple platform repositories can be configured by using the following naming convention:
Where {repoId} is a unique identifier for the repository (e.g., prismeai, backup) and {FIELD} is one of the supported fields listed below.
The filesystem type is reserved for platform repositories and cannot be used in workspace-level repository configurations.
Example (single platform Git repository):
Example (filesystem platform repository, like the one embedded in prismeai-workspaces Docker image):
With this configuration, the platform expects workspace directories directly inside /www/platform-workspaces/ (e.g., /www/platform-workspaces/ai-knowledge/, etc.). Example (with a custom directory path, Git):
With this configuration, a workspace with slug myapp would be stored under workspaces/myapp/ in the repository. Example (multiple platform repositories):
Notes:
  • Platform repositories are returned in the platformRepositories field of the workspace API response; they do not include auth details, and are never persisted into the workspace configuration.
  • Authentication credentials are never exposed in API responses.
  • For GitHub HTTPS authentication, use your username as AUTH_USER and a personal access token (PAT) with read-write permissions on Contents as AUTH_PASSWORD.

Workspace Groups

Workspace groups define logical sets of workspaces that can be imported together via bulk import. Groups are configured through environment variables:
A workspace belongs to a group if at least one of its labels matches one of the group’s labels. When a workspace is pushed to a platform repository, the groups it belongs to are recorded in its .import.yml file. Example:
These group names are then used in:
  • The bulk import API (groups body parameter): POST /v2/workspaces/platform/versions/latest/pull
  • The bulk push API (groups body parameter): POST /v2/workspaces/platform/versions
  • STARTUP_IMPORT_GROUPS to select which workspaces to import automatically on startup

Automatic Import at Startup

The workspaces service can automatically trigger a bulk import when it starts. This is useful for initial deployments and platform upgrades, ensuring that reference workspaces from a platform repository are always up to date. Example:
At startup, the service:
  1. Ensures the platform workspace exists (creates it if needed)
  2. Waits for the platform to be ready (checks the /v2/readiness endpoint, with a 5-minute timeout)
  3. Imports each group sequentially using the bulk import mechanism, with a 30s pause between each group
  4. Skips workspaces already at the correct version (based on .import.yml version matching)
When multiple replicas start simultaneously (e.g., during a rollout), only one replica acquires the write lock on the Platform workspace and performs the import. Other replicas skip the import entirely.

Credentials replayed without a user

A run that carries no user cannot read a workspace secret under anyone’s permissions. That matters for connectors: the OAuth token a member deposited when connecting their account is exactly what a nightly synchronisation needs to replay. There is nothing to configure here, and no operator gesture at all. A workspace declares a role in its own security rules, grants it read over a family of its secrets, and its automations take that role on where they need it. See RBAC and secure secrets.
Such a role can read, and overwrite, every credential in the family it names. It is meant to be assumed by an automation and nothing else: granting it to a person, or attaching an API key to it, hands those credentials to whoever holds them. The platform does not prevent it, so treat it as a rule of your own.

Performance & Limits

Rate Limiting

The variables below are the api-gateway-side rate limits: requests above the threshold are rejected with HTTP 429. For automation rate limits (also RATE_LIMIT_* but on prismeai-runtime), see API Reference: Rate Limits. Unlike the gateway limits, those don’t break execution; they deliberately slow automations down instead of failing them.

Integration & APIs

Examples

S3 Storage Configuration

Authentication and Rate Limiting for Production